The Clean Architecture in php

When to use Dependency Injection
Now that we’ve discussed what dependency injection is and the problems it can help solve in your
code, it’s important to take a moment think about where it is appropriate to use this technique,
and where it is not. This is a bit of a blurry line, and whoever you talk to, you’ll probably get a
different opinion.
Here’s where I think you should use dependency injection:
1. When the dependency is used by more than one component. If it’s being used by many
things, it probably makes sense to abstract out the instantiation and configuration and
inject the dependency, rather than doing it when needed. Without this, we make it hard
to refactor our code that uses this dependency. However, if the dependency is only used
once, you then only have one place to go when refactoring the code.
2. The dependency has different configurations in different contexts. If a dependency is
configured differently in the different places it is used, then you definitely want to inject
it. Again, this configuration shouldn’t take place in the dependent class. Not only does it
make refactoring difficult, but can make testing difficult as well. You’ll probably also want
to invest in a real factory that can create these dependencies under different scenarios to
abstract further the creation of those dependencies.
3. When you need a different configuration to test a component. If testing a dependent
object requires that the dependency needs to be configured differently to be tested, you’ll
want to inject it. There isn’t any other good way around this. Think back to our example
of mocking the
CustomerRepository
to control what data it returned.
4. When the dependency being injected is part of a third party library. If you’re using
someone else’s code, you shouldn’t be instantiating it directly within the code that depends
on it. These dependencies should absolutely be injected into your code. The usage of
someone else’s code is something we might refactor often. Special attention needs to be
paid to this scenario, and we’ll discuss that in detail in
Abstracting with Adapters
using
the Adapter Pattern we’ve already discussed.
But there are definitely some scenarios where you probably don’t want to use dependency
injection.
If a dependency doesn’t need to be configured in anyway (meaning, no constructor arguments
or set methods that need to be called to set it up), and doesn’t have dependencies itself, it might
be safe to go ahead and just instantiate that dependency within the class that needs it. This is
especially true when the dependency is the component within the same layer of the application
(we’ll get to talking about various layers of software in a little bit).
For example, if our framework requires that our controller actions return some kind of view or
response object, it makes perfect sense to just instantiate and return that right in the action.

---

Dependency Injection
49
public function
viewAction
() {
$customer
=
$this
->
repository
->
getById
(
1001
);
return new
ViewModel([
'customer'
=>
$customer
]);
}
There is little gained value from injecting this
ViewModel
class into the controller. It has no
configuration, it has no dependencies itself, and in the case of testing, we probably just want to
verify that an instance of
ViewModel
was returned with an instance of
Customer
stored within
it.