Zend Framework 2.0: Dependency Injection (Part 2)
Image via Wikipedia
In Part 1 of this miniseries, I expounded (it's better than exploding) about Dependency Injection (DI) and Dependency Injection Containers (DICs). To summarise, DI is an obvious and ubiquitous design pattern used daily by most programmers to allow objects accept their dependencies from an external agent (e.g. a unit test which needs to inject mock objects). In an application, the ideal external agent is some container that can assemble objects on demand and create the necessary object graph from scratch outside of the application's control flow. It is this object assembly function that can be fulfilled by a DIC.
For Part 2, we're going to dig more into what a DIC is and isn't. I've already noted one very simple DIC called Pimple which will continue as one of my reference points since it best illustrates just how simple a DIC can be. In Part 3, we'll (finally) turn our attention to some actual source code. Baby steps. Parts 1 and 2 should get you thinking so that ZF 2.0a€˛s DIC is a lot easier to understand and critique. We don't want anyone panicking just by throwing them into the deep end .
Make sure to read Part 1 if you haven't already!
Things Which Are Not A Dependency Injection Container (DIC)
Now, in explaining a DIC it's worth noting there are related solutions which you should find very familiar.
You could use lots of Factories (classes or methods on a class in which the logic necessary to create an object is packaged for reuse). If you followed Part 1, you'd soon realise that the Pimple DIC, as simple as it is, looks very much like a collection of Factory Methods (as Closures). Zend_Application also appears to use Factory Methods or Classes to generate its resources. Along this line of thinking, a DIC is a container of executable Factories. These tend to be the simplest kind of DICs since they rely on source code instructions which can be combined in sequence to assemble a final dependent object and its injected dependencies.
The differences however all come back to the concept of an a€oexternal agenta€ť. Factories are traditionally executed within and by an application object whereas a DIC operates from outside an application. Since this is a simple inversion of control, DICs following this mechanism can be written over a coffee break since it's just a matter of aggregating and mixing Factories - or you can just standardise on Pimple .
Another possible solution is to use a Service Locator. This is often interpreted as an object which can create and retrieve objects. The Service Locator is injected into dependent objects as needed so they can lookup their own dependencies. For example, in our earlier Leprechaun class example from Part 1, we could have created a Service Locator capable of creating Pot classes, injected it into Leprechaun, and allowed the Leprechaun class to lookup whatever Pot it needs.
This too looks very similar to how a DIC appears to operate. It's also similar to a "/
Truncated by Planet PHP, read more at the original (another 11287 bytes)