5 ms·
Every so often a developer challenges the status quo. Why should we do it like this, why is the D in SOLID so important when it causes pain? This is lack of e
by SillyUsername 1y ago
Every so often a developer challenges the status quo.
Why should we do it like this, why is the D in SOLID so important when it causes pain?
This is lack of experience showing.
DI is absolutely not needed for small projects, but once you start building out larger projects the reason quickly becomes apparent.
Containers...
- Create proxies wrapping the objects, if you don't centralise construction management it becomes difficult.
- Cross cutting concerns will be missed and need to be wired everywhere manually.
- Manage objects life cycles, not just construction
It also ensures you code to the interface.
Concrete classes are bad, just watch what happens when a team mate decides they want to change your implementation to suit their own use cases, rather than a new implementation of the interface. Multiply that by 10x when in a stack.
Once you realise the DI pain is for managing this (and not just allowing you to swap implementation, as is often the the poster boy), automating areas prone to manual bugs, and enforcing good practices, the reasons for using it should hopefully be obvious. :)
- timclark 1y agoThe D in SOLID is for dependency INVERSION not injection. Most dependency injection that I see in the wild completely misses this distinction. Inversion can promote good engineering practices, injection can be used to help with the inversion, but you don’t need to use it.
- SillyUsername 1y agoAgreed, and I conflated the two since I've been describing SOLID in ways other devs in my team would understand for years. Liskov substitution for example is an overkill way of saying don't create an implementation that throws an UnsupportedOperationException, instead break the interfaces up (Interface Segregation "I" in SOLID) and use the interface you need. Quoting the theory to junior devs instead just makes their eyes roll :D
- layer8 1y agoLSP is about much more than not throwing UnsupportedOperationException, that’s a complete mischaracterization. ISP isn’t about avoiding UnsupportedOperationException as well, it’s about reducing dependencies.
- SillyUsername 1y agoIn Java land this is really the closest analogy I could create an example for. Do you have better example I could use with Java pls?
- thiht 1y agoHonestly inversion kinda sucks because everybody does it wrong. Inversion only makes sense if you also create adapters, and it only makes sense to create adapters if you want to abstract away some code you don’t own. If you own all the code (ie layered code), dependency inversion is nonsensical. Dependency injection is great in this case but not inversion.
- layer8 1y agoMoreover, dependency inversion is explicitly not about construction, which conversely is exactly what dependency injection is about.
- sltr 1y agohttps://blog.ploeh.dk/2025/01/27/dependency-inversion-without-inversion-of-control/ https://blog.ploeh.dk/2025/01/27/dependency-inversion-withou...
- exac 1y agoAgreed. DI Containers / Injectors are so fundamental to writing software that will be testable, and makes it much easier to review code.
- pydry 1y agoIt's not just not needed for small projects it is actively harmful. It's also actively unhelpful for large projects which have relatively more simple logic but complex interfaces with other services (usually databases). DI multiplies the amount of code you need - a high cost for which there must be a benefit. It only pays off in proportion to the ratio of complexity of domain logic to integration logic. Once you have have enough experience on a variety of different projects you should hopefully start to pick up on the trade offs inherent in using it to see when it is a good idea and when it has a net negative cost.
- jen20 1y agoWhile I agree this is largely a "skill issue", I'm not so sure it's in the direction you seem to think it is. Almost nothing written using Go uses an IoC container (which is what I assume you're meaning by DI here). It's hard to argue that "larger projects" cannot or indeed are not built using Go, so your argument is simply invalid.