4 ms·
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%) wit
by Akronymus 5y ago
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)
- Aeolun 5y agoDI makes testing nice. People approximate it with hacks, but you need DI for truly good unit tests.
- Akronymus 5y agoReally depends on the whole structure. If it is mainly FP, dependency rejection usually is actually the easiest to test with
- Aeolun 5y agoI 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.
- Akronymus 5y agoI was thinking sideeffectful functions. Such as DB accesses.
- layer8 5y ago> dependency rejection That’s secretly the most powerful design strategy.
- Akronymus 5y agoIt objectively isn't, as there are certain things you can't do with it. Altough, for usability it is IMO definitely the best.