Having issues understanding Dependency Injection

Question

I'm building out a small project to try to teach myself as much of the fundamentals as possible, which for me means not using a prefabricated framework (As Jeff once put it, "Don't reinvent the wheel, unless you plan on learning more about wheels" [emphasis mine]) and following the principles of Test Driven Development.

In my quest, I recently ran into the concept of Dependency Injection, which appears essential to TDD. My problem is that I can't quite wrap my head around it. My understanding so far is that it more or less amounts to "have the caller pass the class/method any other classes it may need, rather than letting them create them themselves."

I have two example issues that I'm trying to resolve with DI. Am I on the right track with these refactorings?

Database Connection

I'm planning to just use a singleton to handle the database, as I'm currently not expecting to use multiple databases. Initially, my models were going to look something like this:

class Post {  
  private $id;  
  private $body;  

  public static function getPostById($id) {  
    $db = Database::getDB();  
    $db->query("SELECT...");  
    //etc.  
    return new Post($id, $body);
  }  

  public function edit($newBody) {  
    $db = Database::getDB();  
    $db->query("UPDATE...");  
    //etc.  
  }  
}  

With DI, I think it would look more like this:

class Post {  
  private $db; // new member

  private $id;  
  private $body;  

  public static function getPostById($id, $db) { // new parameter   
    $db->query("SELECT...");  // uses parameter
    //etc.  
    return new Post($db, $id, $body);
  }  

  public function edit($id, $newBody) {   
    $this->db->query("UPDATE...");  // uses member
    //etc.  
  }  
} 

I can still use the singleton, with credentials specified in the application setup, but I just have to pass it from the controller (controllers being un-unit-testable anyway):

Post::getPostById(123, Database::getDB);

Models calling models

Take, for example, a post which has a view count. Since the logic to determine if a view is new isn't specific to the Post object, it was just going to be a static method on its own object. The Post object would then call it:

class Post {
  //...

  public function addView() {
    if (PageView::registerView("post", $this->id) {
     $db = Database::getDB();
     $db->query("UPDATE..");
     $this->viewCount++;
   }
}

With DI, I think it looks more like this:

class Post {
  private $db;
  //...

  public function addView($viewRegistry) {
    if ($viewRegistry->registerView("post", $this->id, $this->db) {
     $this->db->query("UPDATE..");
     $this->viewCount++;
   }
}

This changes the call from the controller to this:

$post->addView(new PageView());

Which means instantiating a new instance of a class that only has static methods, which smells bad to me (and I think is impossible in some languages, but doable here because PHP doesn't allow classes themselves to be static).

In this case we're only going one level deep, so having the controller instantiate everything seems workable (although the PageView class is getting its DB connection indirectly by way of the Post's member variable), but it seems like it could get unwieldy if you had to call a method that needed a class that needed the class that needed a class. I suppose that could just mean that's a code smell too though.

Am I on the right track with this, or have I completely misunderstood DI? Any criticisms and suggestions are greatly appreciated.

Answer 1

Yes. It looks like you have the right idea. You'll see that as you implement DI all your dependencies will float to the "top". Having everything at the top will make it easy to mock the necessary objects for testing.

Having a class that needs a class that needs a class is not a bad thing. What your describing there is your object graph. This is normal for DI. Lets take a House object as an example. It has a dependency on a Kitchen; the Kitchen has a dependency on a Sink; the Sink has a dependency on a Faucet and so on. The House's instantiation would look something like new House(new Kitchen(new Sink(new Faucet()))). This helps to enforce the Single Responsibility Principle. (As an aside you should do this instantiation work in something like a factory or builder to further enforce the Single Responsibility Principle.)

Misko Hevery has written extensively about DI. His blog is a great resource. He's also pointed out some of the common flaws (constructor does real work, digging into collaborators, brittle global state and singletons, and class does too much) with warning signs to spot them and ways to fix them. It's worth checking out sometime.

Answer 2

It's certainly going into the right direction but you should not stop there.

The point of DI is to remove strong couplings between classes to allow for easier substitution of single components. This will allow for better testability because you can substitute dependencies more easily with Mocks and Stubs. And once your code is tested, it is much easiert to change and maintain.

Consequently, you should also remove those other aspects in your code that create strong coupling smells as well, e.g. remove the static methods and the singleton and any other globals.

For some more information on that, please see

• How is testing the registry pattern or singleton hard in PHP?
• http://gooh.posterous.com/singletons-in-php
• http://kore-nordmann.de/blog/0103_static_considered_harmful.html
• http://fabien.potencier.org/article/11/what-is-dependency-injection

---

EDIT: with a couple of others answers suggesting to use a DI container, I feel it's necessary to stress that you do not need a DI container to do DI. The second blog post in the last link given above discusses this.

Answer 3

Dependency injection is about injecting. You need some solution to inject the external object.

The traditional approaches are:

• constructor injection __construnctor($dependecy) {$this->_object = $dependency}
• setter injection setObject($dependency) {$this->_object = $dependency}
• gettter injection getObject() {return $this->_dependency} and oveloading this method eg. from stub or mock in the tests.

You may also mix all the above, depends what you need.

Avoid static calls. My personal rule is use static only when you call some functions, e.g. My::strpos() or when dealing with singletons or registry (which should be limited to minimum, because global state is evil).

You will rarely need static methods when your app has a good dependency container.

Take a look at the other dependency injection + [php] topics on SO.

Edit after comment:

The container

Different frameworks handle the container in different way. Generally this is an object, which holds the instances of objects you need, so you don't have to instantiate new object each time. You may register any object with such a container, and then access it anytime you need.

The container may instantiate all the resources you need at boot time, or lazy load the resource when accessed (better solution).

As an example, consider:

• Zend Application Resource Plugins
• Symfony Dependency Injection Container

Another great reference:

• http://martinfowler.com/articles/injection.html

Answer 4

To answer your questions: yes, you are on the right track. To give you more details: this is one of the best posts I found related to DI:

http://www.potstuck.com/2009/01/08/php-dependency-injection

You will understand what a container is: $book = Container::makeBook();

Regarding the second example: in your method addView I would try to avoid passing the object $viewRegistry, I would check the condition outside in the controller.