The Pope Is Dead ::

Dependency Injection

Posted on 09/12/2009 at 09:10 PM

For a while now I have been looking at Dependency Injection in PHP and have been experimenting with the Yadif DI Container, after much thought I decided to stop creating the article on ZF and Yadif as I now believe that in PHP a DI Container is overkill. This article is therefore an explaination of the general DI principles that we all can use to improve our code and why DI Containers are overkill in PHP.

Dependency injection (the problem)

Dependency Injection is a design pattern that deals with object configuration or object dependencies. By a dependency we mean that an Object uses another Object or Service, this brings us to the problem of how an Object handles it supporting services. The easiest way to look at this is through an example, consider the following class.

In class Foo we need to use the supporting database connection, to do this we instantiate a new dbConnection class in Foo’s constructor. This seems like a totally reasonable way to give our class access to the database connection, however by doing this we are giving Foo control over its own configuration (dependencies); this causes us the following problems.

• We cannot replace the database dbConnection instance when testing as we have no control over its instantiation.
• Foo must know how to configure the database connection which breaks the encapsulation of our object.
• We cannot easily change the dependencies of Foo, to do so we must edit the code.

So basically when we have a new call within our class we create a tight coupling between our objects. To solve this problem we need to configure the object from the outside rather than from within, we can do this using Dependency Injection which injects the dependencies into the object and takes control over the objects dependencies.

Types of dependency injection

To start we will look at some basic types of Dependency Injection, we can easily use these techniques in any application without the need for a Dependency Injection framework, though we still use these techniques even with a framework.

Constructor based injection

Constructor injection is where we inject our dependencies via the objects constructor method; if we now go back to the Foo example we can refactor that class to support constructor injection.

We can see that we have only had to make minor changes to the class to implement constructor injection. To do this we now pass the dbConnection class into Foo via a constructor parameter, meaning to use Foo we now do:

The dbConnection class is now injected into Foo, meaning we can easily replace it and have removed the responsibility of instantiation from Foo.

As we can see this is very simple and I am sure we have all already done similar things in our code but maybe without knowing. We can also further improve this by introducing an interface, currently the constructor parameter is type hinted as dbConnection meaning we can only pass in instances of dbConnection or subclasses of it.

By introducing an interface for dbConnection we can now easily create many different types of dbConnection that Foo can use, Foo will know how to use each connection type as they will all share the same public interface. Generally this is good practice when injecting dependencies as it make our implementation much more flexible.

Setter based injection

Setter based injection is just as simple as constructor based injection, however this time rather than providing our dependencies in the construct we provide them using a setter method.

Going back to our example we can refactor Foo to use setter injection.

We can see this is a fairly simple refactoring of Foo, this time we can inject our dependency via the setter and retrieve it via its getter. So which type of injection is best? Well really both are valid, using constructor based injection you can be certain that your dependency will not be forgotten to be injected as they are required to instantiate the object, with setter based injection you could forget to inject your dependency. However, with setter based injection you can get around this using Lazy Injection, which we will look at next.

Lazy injection

When using setter based injection we could possibly forget to inject a dependency, also if we have a large amount of dependencies our code could look like this:

An awful lot to remember when instantiating an object, also we are lazy programmers so we never want to type this much!

Here we have simply added an if statement into the getter method for the database connection and if the _db property has not already been set we instantiate a new default dbConnection object. This affectively lazy loads our dependency for us if we have not already set one. By no means is this a perfect solution to our problem, what if we need to configure the dependent class too? Well, we then get horrible situations where we have configuration code with our classes or code that fetches the configuration or we go for more lazy configuration and so forth. So this is not perfect but at least it does solve some of our problems, this is why you will notice that I use it a lot in the Storefront application!

Unified Constructor

Another important technique to note is the Unified Constuctor, this is used in many ZF components already and provides a powerful way to configure an object. Whilst this is not strictly Dependency Injection we should be aware of it as it can be used in conjunction with Lazy Injection to good affect.

The idea of a unified Constuctor is to allow options/config to be passed into the constructor of the object that requires configuration, this then creates a construct that looks the same for many objects giving us the unified name.

To fully explain lets look at an example.

So here we can see that Foo now accepts $options in its construct, $options will be either and array or Zend_Config instance that contains the objects configuration. The setOptions() method is called from the construct and simply iterates over the $options array and calls the setters that match the keys in that array. This means that along with the Lazy Injection we can now override the default database connection using the unified construct.

This again lets us configure our objects from outside and breaks up those tight dependencies, there are some obvious drawbacks to the unified construct mainly that intellisense does not work and the code is not as clear as it could be as you need to know what the options are, though they do match the setters anyway.

Dependency Injection Containers

At this point I was going to show how we can use the Yadif DI Container to move all object configuration outside of our objects, however as I mentioned earlier after some discussion and research I now believe that the use of a DI container in PHP may be overkill in most situations.

So what does a DI Container look like?

The $config variable would contain a set a configuration instructions that tells the container how various object or components should be instantiated and configured. Therefore, we would retrieve all new objects via the container and would never use new to instantiate our objects, pushing all instantiation and wiring to the container.

So whats the problem? This does look like a very reasonable approach when you have many dependencies, however as PHP is a dynamic language that is generally used in a web environment we have a problem with the amount of objects that are created and potentially never used. Consider the following diagram.

If we were to retrieve A from the DI Container the Container would automatically instantiate six other objects, these in turn could create other objects and so on. This in PHP can become impractical as generally we are running in a stateless environment and many of these objects may never be used and take up memory. In Java this approach does not matter so much as it is stateful and eventually the objects will be used.

With this in mind I would only use a DI Container if you are running PHP in some sort of stateful environment. For now I would suggest using a combination of Lazy Injection, Unified Constructor and Factories to wire you objects, though a small DI Container used carefully can still be helpful.

Conclusion

A big part of Dependency Injection is helping us to create testable code, all the manual DI techniques I have covered here help to create a testable codebase even without the use of a DI Container. Remember the biggest killers for testable code are:

• Global State
• new calls within your code
• Singletons (these are global state)
• Static calls (global state again...)
• PHP Function calls (global state yet again...)

So to sum up, Dependency Injection techniques are very valuable in our day-to-day programming, enabling us to create easy to test code. DI Containers probably should be used only with great care in PHP.

Footnote 1: If you are interested in Yadif or want to see a DI Container in action I have released code for the Storefront which I used in my experiments. Google Code - Yadif & Storefront

Footnote 2: Remember we can use Lazy Injection to guard against all the bad things for testability not just new calls.

Footnote 3: To guard against PHP core function cores which are in the Global Scope we can make a proxy class.

By creating a class that proxies to the global PHP functions we can now cleany replace calls to them within our classes during testing.

Hi Keith,

first I want to say that I read your book and liked it very much! Now I have a question about this article. What is the difference about the direct instantiation of the db object (first example) and the lazy injection example? Is the instantiation in getDb only a fallback if I missed to inject the db earlier or do I never call setDb myself with intent? Both cases are dangerous if I got your idea right. In the first case I have no real dependency injection, because the db object is instantiated in the foo class directly like in the first example. It just moved into another function. And the in second case I have a problem if I changed the injected db object somewhere in the past and now I want to use foo object and forget to inject the db object. The lazy loader now loads the old db object directly instantiated in the getDb class. Is that right or did I missunderstand the idea? Would a factory be usefull in this case to handle all the injections (setDb, setLog, setCache...)?

Lazy injection acts to create a default dependency, so in normal use the db, log etc uses the “real” object or default.

When testing we can then instantiate the object and inject a mock or stub before we start testing.

$myFakeObject = new StubDb();
$myObject = new Foo();
$myObject->setDb($myFakeObject);

This way we can control the dependencies from outside and in normal use we do not need to remember to inject all the dependencies.

Thanks… now I understand. Missed the testing aspect. Testing is unfortunately no common programming technique here :-/