The Dependency Injection Paradigm
Paradigm; a nice word that means "a theory or a group of ideas about how something should be done, made, or thought about" (Merriam-Webster). In software development we have them too. From the philosophy and history of science courses I've followed, I remember that scientists working with different paradigms have great difficulty understanding each other, and appreciating each other's work.
Paradigm Shifts
An example of a paradigm is the theory that the sun revolves around the earth. To a certain extent this is a fruitful theory, and it has been used for thousands of years. There's of course another paradigm: the theory that the earth revolves around the sun. This is also a fruitful theory, and it can be used to explain a lot of observations, more than the previous theory. Still, people got angry with each other for moving the earth out of the center of the universe. Paradigm changes, or shifts, occur when the old theory has been stretched too much. It becomes impossible to hold on to it. Then some people start to experiment with a completely different paradigm, one that sounds totally weird, but in the end proves to have more power.
Now back to software development: we have paradigms and paradigm shifts too. For example, PHP went from being a very dynamically typed language to being a more statically typed language. This is weird for some, but great for others since it unlocks new possibilities, like static analysis and automated refactoring.
The DI Paradigm
Another paradigm shift happened years ago when we went from symfony1 to Symfony 2, which introduced the Dependency Injection container. The idea of Dependency Injection was quite new to many developers back then, and we had to talk and read about it a lot before we were ready for this amazing yet weird concept. What got in the way of adoption, I think, was the Yaml or XML syntax for service definitions, an approach that was probably copied from Spring. If we'd start by writing our own service containers in plain PHP, that would've been much easier to learn and do.
What's interesting to me is that Symfony's first DI container was showing some influence from the old paradigm, e.g.
- Singleton services: most services are instantiated only once, which allows for stateful services, mimicking the actual singletons from before.
- The container had services that aren't services (e.g. the current HTTP request object).
Nevertheless, we got a taste of DI: expect your dependencies to be injected, instead of having to fetch them yourself. This changes everything!
- Dependency injection is inversion of control: a service doesn't have to be worried about setting up a dependency, it can just declare it, and it will be taken care of.
- Depending on an interface gives the developer the option to switch out implementations, for whatever reason.
- Looking at the constructor signature, you can get some idea of what the service is going to do, and a complete overview of what it needs.
- If a class is not a service, you can't give it service dependencies. This makes it absolutely clear what type of object a class represents: it's either a service, or some other object like an entity, or a value object.
I was totally convinced that the Dependency injection paradigm was a step forward, out of the land of unclear dependencies and tightly coupled classes. And I thought every other developer would like it too. Surprisingly, the introduction of a new framework - Laravel - revived the old paradigm, and with great success. It's surprising because a paradigm shift isn't often reverted. In science, the paradigm shift indicates a step forward, towards a theory that can explain more phenomena than the previous paradigm could. In programming, it turns out, you can have developers working with different paradigms, and even arguing that neither of those paradigms is a step forward compared to the other.
Crossing the Bridge
When I, as a developer from the DI paradigm, talk to someone who uses another paradigm, I find it really hard to come to some form of understanding. The assumptions, the goals, the theories that each of us uses, are very different. I find this very hard to deal with. We talk about a piece of code and I see lots of problems with it, but there is no common ground that can help us settle the debate. Personally I'm sad about this, because I don't really know how to improve the situation. You can keep fighting, and this happens a lot (e.g. on Twitter, Reddit), but since developers use completely different paradigms, I think that produces only negativity. In the case of "S
Truncated by Planet PHP, read more at the original (another 1699 bytes)