Having issues understanding Dependency Injection

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.

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

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.