this post was submitted on 02 May 2024
401 points (92.8% liked)

Programmer Humor

19652 readers
2205 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 6 points 6 months ago (7 children)

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.

[–] [email protected] 3 points 6 months ago (4 children)

Isn't the point of injecting classes so that you don't have tens of instances of the same class in memory?

[–] epyon22 12 points 6 months ago (2 children)

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.

[–] porgamrer 7 points 6 months ago* (last edited 6 months ago)

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.

[–] MajorHavoc 3 points 6 months ago

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.

load more comments (1 replies)
load more comments (3 replies)