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:

<?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).

<?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.

Frustrated with your company’s development practices? You don't have to be! No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist. Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."

Great! We'll be updating you soon on best practices for your team!

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP