php dependency innjection

You’ve probably heard of the acronym SOLID by now, which is an object oriented programming paradigm consisting of five basic (but interrelated principles) of object oriented development.

And you’ve probably heard once or twice that the D in SOLID stands for Dependency Injection. Actually, if you’re lucky you’ve also heard what it really stands for, which is the Dependency Inversion Principle. But, in PHP, this is often conflated with dependency injection.

I’m here to tell you today that dependency injection is only one piece of the overall puzzle in understanding this crucial principle.

The Dependency Inversion Principle states that:

Do not depend upon concretions; depend upon abstractions instead.

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.

Dependency injection is often cited as one way of complying with this principle, by injecting dependencies into lower level modules rather than depending on concrete instances that are created in the lower levels. But this is only one part of the dependency inversion principle.

This particular principle also hinges on the concept of “dependency on abstractions.” When type hinting in PHP it is possible to type hint on a concrete instance of a class (e.g. a type that can be instantiated and used). However, this makes an object just as dependent on a concretion as it would be if it was instantiating the object directly; while it becomes easier to write tests with this mechanism, we are still no better off in terms of depending on an abstraction. For example:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<?php   class myClass {       public function __construct() {         $this->myDatabase = new Database();     } }   class myOtherClass {     public function __construct(Database $db) {         $this->myDatabase = $db;     } }

Other than the improvement in testability of myOtherClass over myClass, there is no difference in the dependencies of the two classes. They are both dependent upon the concrete class Database.

Instead, it is better for us to depend upon a defined interface or abstract class. By type hinting on the interface, rather than the concrete implementation of the interface, we are depending upon the abstraction provided by the interface and honoring the dependency inversion principle completely. Additionally, because we are using an interface, the second part of the dependency inversion principle is honored as well (details depending upon abstractions).

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<?php   class myClass {       public function __construct() {         $this->myDatabase = new Database();     } }   class myOtherClass {     public function __construct(Database_Interface $db) {         $this->myDatabase = $db;     } }

In the second example, there is a huge difference between the two classes: the myOtherClass object is now dependent upon an abstraction of Database through Database_Interface; that interface can be implemented in any way that the developer needs or wants and will still work with the myOtherClass code. This honors the dependency inversion principle through dependence on abstractions as well as through injection of dependencies.

http://www.brandonsavage.net/the-d-doesnt-stand-for-dependency-injection/

There is a difference, but it’s subtle.

The Liskov substitution principle says that objects should be replaceable with instances of their subtypes. By type hinting an abstraction we are making that true. If we were talking about type hinting, this would be an article on LSP.

However, this relates to dependency inversion because we are focusing on the relationship of an object to its dependencies, which should be abstractions, not concretions. The only way in PHP to depend upon abstractions is to type hint an abstraction.

The difference is subtle, but there. And LSP and DIP are very closely related. In fact, all of the SOLID principles relate to one another in that it’s nearly impossible to apply one without applying all of them