It also sounds fancier than it really is. "Dependency injection" can literally mean just passing some arguments or setting properties on a hash. The target doesn't even need to be a singleton or long-lived. Honestly, I've never found the term particularly useful. The meaning is so amorphous that it could really just be described as a form of decoupling. But it sure was great to say it during interviews early in my career!

Indeed, it is simply passing some dependency as a parameter.

Personally I find DI to make it harder to reason about in a sizeable portion of cases (20ish%) without actually providing a benefit.

So that makes me prefer going for rejection (Passing the result of the dependency instead of the dependency itself) or just keeping it there.

Altough, those approaches depend heavily on the rest of the codebase. (FP makes rejection relatively easy for example)

DI makes testing nice. People approximate it with hacks, but you need DI for truly good unit tests.

Really depends on the whole structure. If it is mainly FP, dependency rejection usually is actually the easiest to test with

I dunno how you can combine dependency injection (as I imagined it in the original comment) with FP in the first place.

Without classes what would you be injecting? Other functions? That’s still something that happens all the time in FP.

I was thinking sideeffectful functions. Such as DB accesses.

> dependency rejection

That’s secretly the most powerful design strategy.

It objectively isn't, as there are certain things you can't do with it.

Altough, for usability it is IMO definitely the best.

> setting properties on a hash

Nowadays it's called a dict.