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

Programmer Humor

19555 readers
490 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] 3 points 6 months ago (2 children)

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

[–] [email protected] 4 points 6 months ago

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 days without trying to wind up other senior developers.

[–] [email protected] 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.

[–] [email protected] 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.

[–] [email protected] 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.