Design Patterns are useful and a must have. Everybody working seriously on software projects should know about them. End of 2007 I decided to use the powerful Spring Framework at my new enterprise project.  The project, which ended these days for me, was a huge success. We made complex changes easy, had very good unit testing and all that stuff. We had up to 12 developers working on the code, I am really thinking that Spring did lots for our success. It was so easy to seperate all the modules and integrate new features within minutes. I am writing this in my article about Dependency Injection, cause Spring highly depends on this design pattern and PIWI will do that, too.

Design Patterns – all just theory?

If students make their exams and come as junior programmers to my projects, they often believe a design pattern is something to eat. Or something theoretical. Or simply a joke. I usually start with explaining how to use it and such, but at the first glance it seems to abstract to them. Later, with the expierence, comes the joy.

This is true for patterns like Singleton or Factory or maybe Model-View-Controller. Coming to Dependency Injection – which is not read very often in Books about good software design – most people NEVER have joy. In this kind it behaves like the Proxy pattern. One really cannot use this out of the box. I mean, a singleton can be implemented within minutes, and it does what it does. But Dependency Injection? It’s more a concept of software design than a design pattern. Can you implement a singleton? Yes. Can you implement Dependency Injection? No, of course not. Having that said, the joy and the power comes when you are using a fitting framework which supports the design pattern. Like Spring. Or PIWI, in the latest trunk version. Cause we PIWI-folks simply have stolen much of the ideas of Spring and now use it not only in Java, but in PHP5 too.

What’s all about it?

Basically Dependency Injection simply says: don’t make a class dependent from another, inject the dependency. So what? some will say. But it’s simple. Imagine the following PHP lines:

class Car {
   private $driver = null;

   public crash() {
      $this->driver->saySomething();
   }
}

You see, there is a private member called driver in the car class. If your use case is that each car is a driver, it’s quite easy in most cases. Just fill the member in the constructor. This is, what most people do. This makes $driver nullsafe.

class Car {
   private $driver = null;

   public __construct() {
      $this->driver = new Driver();
   }

   public crash() {
      $this->driver->saySomething();
   }
}

OK. From this point on the class Car depends on the class Driver, cause you need the Driver class to instanciate Car. After you did that and all works well, your boss looks round the corner and tells you that we need to distinguish between female drivers and male drivers. He is sorry for saying that so late, but it’s like this. Cause if you call the new method crash(), a female driver would simply say:”you crashed me!” and a male driver would say something like:”guy i have a gun!”. And, that’s the point, your client A just wants male drivers in their systems, while client B just needs female drivers.

People start doing:

class Car {
   private $driver = null;

   public __construct($client) {
      if($client == "A") {
         $this->driver = new MaleDriver();
      } else if($client == "B") {
         $this->driver = new FemaleDriver();
      }
}

   public crash() {
      $this->driver->saySomething();
   }
}

All is good. But what if you need to port the system for somebody who just let childs drive? Or people with glasses upon their noses? In fact, we had the requirement to create several modules for several clients – customization. Yes, the example above with male and female drivers is not the best, but I am sitting in a car while typing this.

Problem on the approach above is that you need a new if else if you ever have more Driver types than above. And you have to put this in class where such dependencies exist. Maybe it’s not pretty much, but in our case we had about 20 modules – without customizations. I really was afraid before such a switch.

Dependency Injection for the solution

As I allready told you, we had Spring and Java 6 in our system. But we ported dependency injection to PIWI. And if you are using one of these frameworks, you know that both heavily use XML. Imagine you could say in an XML which driver you want to use. More better: you really would define an interface for all the driver classes and would make sure that you operate on that interface only.

See this:

interface Driver {
   public saySomething();
}

class FemaleDriver implements Driver {
   public saySomething() {
      echo "You crashed me!";
   }
}

(imagine something similar for MaleDriver).

You could do something like that:

class Car {
   private $driver = null;

   public __construct($driver) {
      $this->driver = $driver;
   }

   public crash() {
      $this->driver->saySomething();
   }
}

Isn’t your code much cleaner now? You know, if else means death to object orientation! This way your Car class doesn’t depend to MaleDriver or FemaleDriver. In case of PHP5 it just depends on an untyped object. In case of Java it depends on the Interface Driver.

By the way: you can force types in PHP5 (in some level of course). You could write the constructor like this:

public __construct(Driver $driver) {
   $this->driver = $driver;
}

This forces the caller to put an object inside which implements the interface Driver. And this in fact is the way you should go! And this is all about the Dependency Injection pattern. It says, make your classes dependend on interfaces, not on classes.

So, isn’t it nice? But how do you decide to bring your dependency in? This is another point, and this is why I said you have to check out Spring or PIWI for this. The example above is working gorgeous, but if you don’t find a mechanism to bring your dependencies into the game, all is lost. I promised XML like Spring does, and here it is: PIWIs XML file for Dependency Injection in PHP.

<bean id="xmlPage" class="XMLPage" scope="request">
   <property name="contentPath" php="$GLOBALS['PIWI_ROOT'].CONTENT_PATH" />
   <property name="siteFilename" value="site.xml" />
</bean>

<bean id="siteSelector" class="SiteSelector" scope="request">
   <property name="page" ref="xmlPage" />
</bean>

We call our objects beans, like Spring does. It’s Spring-Beans in Spring, but PIWI-Beans in PIWI. We are shameless. First, look at the bean definition with the id xmlPage. You give it a class and a scope, and some properties.

Basically, PIWI (and Spring too) creates the objects for you. That has many benefits. I will write an blog article why instanciating objects yourself is sometimes a bad idea some day. However, PIWI makes an object and stores it in our context, the BeanFactory. It’s stored under the id xmlPage, and you can get the object manually if you call:

$xmlPage = BeanFactory::getBeanById('xmlPage');

This brings you the ready bean. Additionally you tell the BeanFactory that it should set the property “siteFilename” to “site.xml”. And one line above you even give it an PHP expression. After PIWi made the object from the class XMLPage, it checks if a member variable is accessible named siteFilename. If it isn’t it looks if there is a method called setSiteFilename($o); or siteFileName($o). If PIWI found that method, it calls it with the value.

This is all done by reflection, which has been shipped with PHP5. No dependencies to other libs, no problem. Just plain PHP5. Same goes to Java. Plain Java. No Magic. Just some reflection.

If you would have called this line instead of the one above:

$siteSelector = BeanFactory::getBeanById('siteSelector');

the BeanFactory would have created the siteSelector bean. If you look into it, you see this:

<property name="page" ref="xmlPage" />

If the BeanFactory gets aware of this (and it does!), it will look in the context for a PIWI Bean with the ID xmlPage. If there isn’t one, it will try to create such a bean. Same rules as above. After creation of xmlPage it will be set into SiteSelector’s setPage($xmlPage) method.

And now imagine how your boss would love it, if you tell him that such a customization is just a matter of some XML?

<bean id="maleDriver" class="MaleDriver" scope="request" />
<bean id="femaleDriver" class="FemaleDriver" scope="request" />

<bean id="car" class="Car" scope="request">
   <property name="driver" ref="maleDriver" />
</bean>

Everthing done!

For the sake of completness – what do we mean with scope? Well, scope is in which scope your object lives. Defining request means, the we create maleDriver only once while the whole request. If you define another class which needs maleDriver, it would get – exactly the same -. This is, what some people call a Singleton in PHP. But Singletons are worth an own Blog entry, since some people – esspecially who have just written code with PHP and not for Java Enterprise Systems – say, Singletons are evil. Well, they are not. If developers are not thinking while coding, that is evil You can misuse everything, if you want to.

Here is another example for using the driver more than once:

<bean id="maleDriver" class="MaleDriver" scope="request" />
<bean id="femaleDriver" class="FemaleDriver" scope="request" />

<bean id="car" class="Car" scope="request">
   <property name="driver" ref="maleDriver" />
</bean>

<bean id="truck" class="Truck" scope="request">
   <property name="driver" ref="maleDriver" />
</bean>

In this case, only the same instance of maleDriver makes it to the truck and to the car. Decide yourself if this is your usecase. In the MaleDriver class are no states defined – so one object is enough.

OK – Dependencies are out. Instanciation is out of the code too. But is this the whole benefit? Not really. This stuff makes it possible to create dynamic proxies and use aspect orientation, even with PHP. And be sure, PIWI will have features some day. And Spring still got this cool stuff. But that’s another story.