Dependency injection has become a relatively common concept to ask during technical interviews. While it is the generally accepted best practice in modern PHP development, it seems terribly little understood beyond the provisions exposed by 3rd party libraries and frameworks.
Perhaps the most common explanation of DI (dependency injection) is a literal description such as passing objects into a constructor. This is, however, neither sufficient nor a satisfying explanation to an interview question or an introduction to the uninitiated.
While many things are said about DI, it's foremost purpose is the decoupling an object's creation from its usage. In practice, this is usually achieved by having a class define and require its dependencies rather than instantiating the dependencies by itself. This forces the "passing objects into the constructor" during object construction which is often cited during discussions of DI.
Not to be pedantic but I think it is important to know the advantages of DI despite already knowing the "motions". Primarily because, the knowledge can help maximize the returns of DI and justify the "overhead" of routing individual dependencies through the constructor rather than just using them outright wherever (as with Laravel facades, static methods, or instantiating dependencies on the spot).
Perhaps the most underrated advantage of DI is a strong decoupling of implementation – that is, dependencies can be of any implementation so long as the interface required is met. This is only possibly since we remove the responsibility of object creation which needs an exact concretion. It is then a matter of expressing the object's dependencies as abstractions such an interface or class to make them "swappable" with other objects implementing the same interface or inheriting the class.
Another major advantage of DI is it naturally leads to the use of a DI container which takes over the responsibility of object creation, dependency resolution, and allows instance re-use. Best of all, there are already several excellent open source DI container implementations which means a huge effort saved and massive gains in code quality.
I can personally recommend Symfony's DI component and PHP-DI which I've both enjoyed using.
Another great benefit to dependency injected services is the possibility of employing an open-closed approach (think Open-Closed principle) when introducing new behavior or updating an existing one. Rather than modifying a class, we can simply create another one or extend the original and implement the new behavior. The new class can then be swapped with the original class wherever the new behavior is needed.
interface Logger
{
public function log(string $message);
}
class NoisyLogger implements Logger
{
public function log(string $message)
{
echo "$message\n";
}
}
class MutedLogger implements Logger
{
public function log(string $message)
{
// no-op
}
}
class Router
{
private $logger;
public function __construct(Logger $logger)
{
$this->logger = $logger;
}
public function route(string $path): void
{
$this->logger->log("Routing $path...");
return $controller;
}
}
if ($isSilent)
return new Router($pathToClassMap, new MutedLogger());
return new Router($pathToClassMap, new NoisyLogger());
To illustrate, say we have a Router class which logs information on what it is doing. Some need arises such that we need to be able to conditionally disable the Router from logging anything. Without modifying the class, we can achieve this simply by instantiating a Router with a different Logger.
Despite being a best practice, there are some situations where DI is unsuitable and it usually means there are bigger design issues to address.
1. God classes — classes that are responsible for and do several things — are terrible candidates for dependency injection. Some objects are expensive to create such as wrappers for database connections. With God classes, DI would result in all dependencies of the God class to be instantiated regardless of whether it will be used. And as God classes are typically used in a lot of places, this could result in a systemic performance hit.
2. Another unsuitable scenario are classes with circular dependencies. Formally defining the dependencies of such classes in order to enable DI will actually make it impossible to instantiate the classes.
Knowing the why of DI as well as its strengths and weaknesses is helpful in reasoning about and communicating software design choices. It also enables fully taking advantage of DI when available and avoiding some potentially nasty pitfalls from blindly following best practices — especially when dealing with legacy code.