At work we have a lot of old monolithic OOP PHP code. Dependency injection has been the new way to do things since before I started and it’s basically never used anywhere.
I assume most people just find it easier to create a new class instance where it’s needed.
I’ve never really seen a case where I think, “dependency injection would be amazing here” I assume there is a case otherwise it wouldn’t exist.
When we implemented it significantly improved our ability to write unit tests. It also allowed us to make more modular code due to the default of every class having an interface. So I’m all for it.
In my opinion dependency injection solves a problem that doesn’t need to exist, and does it by adding even more obfuscation and complexity.
The problem is that the original gang of four design patterns had very little to say about managing effects. In old java code things like network and file IO often happen deep inside the object graph, hidden behind multiple impenetrable abstractions such that it’s impossible to run the logic without triggering the effect.
The wrong solution is to add even more obfuscation and abstraction, so that you can inject replacement classes deep inside the object graph where the effects happen. it solves the immediate problem of implementing tests, but makes everything else worse and more confusing.
The right solution is to surface all your effects at the top level of the call graph. The logic only generates data, and passes it back up to the top level of the program. The top level code then decides whether to feed this data into an effectful operation. Now all your code is easier to reason about, and in you can easily test the logic without triggering unwanted effects.
Yeah. Injection has a place in test patterns. Thankfully, it’s usually possible to hide injection from strongly affecting anything else that matters, as long as the team hates injection deeply enough.
As a fellow PHP dev (working in laminas specifically) DI actually is fucking awful, there’s a distinction between a service factory pattern and this thing called DI which is similar to a service factory pattern but uses reflection based type sniffing to guess at which service you want where. I’d considered making a reference to it but PHP developers are few and far between these days.
At work we have a lot of old monolithic OOP PHP code. Dependency injection has been the new way to do things since before I started and it’s basically never used anywhere.
I assume most people just find it easier to create a new class instance where it’s needed.
I’ve never really seen a case where I think, “dependency injection would be amazing here” I assume there is a case otherwise it wouldn’t exist.
Isn’t the point of injecting classes so that you don’t have tens of instances of the same class in memory?
When we implemented it significantly improved our ability to write unit tests. It also allowed us to make more modular code due to the default of every class having an interface. So I’m all for it.
In my opinion dependency injection solves a problem that doesn’t need to exist, and does it by adding even more obfuscation and complexity.
The problem is that the original gang of four design patterns had very little to say about managing effects. In old java code things like network and file IO often happen deep inside the object graph, hidden behind multiple impenetrable abstractions such that it’s impossible to run the logic without triggering the effect.
The wrong solution is to add even more obfuscation and abstraction, so that you can inject replacement classes deep inside the object graph where the effects happen. it solves the immediate problem of implementing tests, but makes everything else worse and more confusing.
The right solution is to surface all your effects at the top level of the call graph. The logic only generates data, and passes it back up to the top level of the program. The top level code then decides whether to feed this data into an effectful operation. Now all your code is easier to reason about, and in you can easily test the logic without triggering unwanted effects.
Yeah. Injection has a place in test patterns. Thankfully, it’s usually possible to hide injection from strongly affecting anything else that matters, as long as the team hates injection deeply enough.
Could be. There’s easier ways to minimize instances in memory. That’s what GLOBAL variables are for.
P.S. I have now gone:
0 dayswithout trying to wind up other senior developers.As a fellow PHP dev (working in laminas specifically) DI actually is fucking awful, there’s a distinction between a service factory pattern and this thing called DI which is similar to a service factory pattern but uses reflection based type sniffing to guess at which service you want where. I’d considered making a reference to it but PHP developers are few and far between these days.
There are dozens of us