Magento 2 uses constructor injection as a part of the move towards dependency injection. This is a quick post on why I personally believe constructor injection is the best approach.

And to give appropriate credit, it was the core team and individuals like Anton Kril that drove the introduction of dependency injection in Magento. I just agree they made the right choices.

What is Dependency Injection?

There are some good write ups around for those who want to dig deep, including on Wikipedia and on the Symfony site. I have written up on dependency injection before as well. Put simply, the idea of dependency injection is for classes to accept objects they need from the outside, rather than calling ‘new’ on a class directly. As soon as your code invokes ‘new’ on a class, it becomes tightly bound with that class. When the needed objects are injected (supplied from outside the class), a subclass can be swapped in instead of the original class or an interface.

There are a number of benefits of dependency injection, including:

• Unit tests are frequently easier to write by replacing real classes with mock implementations.
• Looser coupling means the code base becomes more extensible and modular, which is important for Magento.
• Code written to be compatible with dependency injection works even if a dependency injection framework is not used. You can replace the dependency injection framework or even drop it completely without changing a single line of application code (unless that code decides to interacts with the dependency injection framework directly, which is discouraged).

Constructor Injection

Magento 2 supports constructor injection. This is where the constructor is provided in constructor parameters all the external resources the class needs. The constructor has one parameter per external object to be provided which it then saves away in properties for usage later by methods of the class.

class MyClass {

    /** @var string */
    private $property1;

    /** @var OtherClass */
    private $property2;

    /**
     * Constructor.
     * @param string $property1
     * @param OtherClass $property2
     */
    public function __construct(
        $property1,
        OtherClass $property2
    ) {
        $this->property1 = $property1;
        $this->property2 = $property2;
    }

    ... rest of class ...
}

The biggest negative of constructor injection is the verbosity of code. You need to declare a parameter per external object in the constructor, a PHP Doc @param for each parameter, a property (with PHP Doc) for each parameter, and you need to copy each parameter to each property.

While verbosity is a negative, the other approaches I believe are worse, as I describe below.

Setter Injection

Rather than having a long parameter list, another approach is to have a ‘setter’ method per value to be injected. Each setter copies the function parameter to the property. The constructor then has a much shorter argument list.

class MyClass {

    /** @var string */
    private $property1;

    /** @var OtherClass */
    private $property2;

    /**
     * Constructor.
     */
    public function __construct() {
    }

    /**
     * Set property 1.
     * @param string $property1
     */
    public function setProperty1($property1) {
        $this->property1 = $property1;
    }

    /**
     * Set property 2.
     * @param OtherClass $property2
     */
    public function setProperty2(OtherClass $property2) {
        $this->property2 = $property2;
    }

    ... rest of class ...
}

Reasons I dislike setter injection include:

• The object is not fully constructed and usable when the constructor function returns. This feels “wrong”. I prefer the object being completely usable when the constructor returns.
• If new properties are added to an existing class, setter injection does not guarantee that all will be found and set. New properties may be missed. Constructor injection will ensure all properties are always set.
• Setters encourage objects to be changed after creation. I prefer objects to minimize change over time.
• Setter methods may be intended to exist only for the dependency injection framework to use – but it is hard to document / control this.
• The code can be even more verbose than with constructor injection due to having lots of small setter methods. “Magic methods” can reduce boilerplate text, but introduce their own problems.

Property Injection

Property Injection is another approach where annotations are used on the properties to identify them to the dependency injection framework to populate. (I made up an “@autowired” annotation for the sake of this example – it does not really exist.)

class MyClass {

    /** @var string @autowired */
    private $property1;

    /** @var OtherClass @autowired */
    private $property2;

    /**
     * Constructor.
     */
    public function __construct() {
    }

    ... rest of class ...
}

The benefits include significantly less boilerplate text – there are no constructor arguments, not setters. Only properties need to be declared. This is pretty clean in terms of code readability.

The negatives include:

• The code is now dependent on the existence of a dependency injection framework. There is no way to just call the class constructor and have it set up.
• Properties can only be injected after the constructor has been called. This means the constructor code cannot safely use the properties, sometimes resulting in a second method call needing to be made to finish the construction flow.

While there is a lot less code, the drawbacks are not acceptable to me. (But for a class with lots of parameters for the constructor I must admitting to being sorely tempted at times.)

Is There No Other Way?

Is there any way this could be made nicer? In PHP, not that I know of, but I am not a PHP expert.

One language that shows how nice it could be however is Scala. When you declare a constructor in Scala the parameters automatically become properties that any function in the class can access at any time. It is like the parameters are automatically copied into properties for you behind the scenes. The properties are also read-only, so you cannot accidentally change them. Making up possible syntax for PHP 29, this might look something like:

class MyClass {

    /**
     * Constructor.
     * @param string $property1
     * @param OtherClass $property2
     */
    public function __construct(
        private property string $property1,
        private property OtherClass $property2) {
    }

    ... rest of class ...
}

Another approach is to supply the dependency injection arguments in a single array. This would reduce the number of constructor and @param declarations, but would still require properties to be declared and the constructor arguments copied into. You could save the whole array as a single property, but I personally like having separate properties with types, allowing IDEs to do things like autocompletion.

Conclusions

In conclusion, out of the choices of constructor, setter, or property injection, I think constructor injection is the best approach. The extra text required *is* annoying, but it is better than the other options (at least until PHP 29 comes along – and yes, that is a joke).

It should also be said that a class with a large number of constructor parameters may have other issues than just the length of the constructor parameter list. How many other classes should one class depend on to be considered well designed?

Disclaimer: This post is my personal opinions and not that of my employer.