Hacker News new | past | comments | ask | show | jobs | submit login

How else are you going to manage dependent options of an algorithm but to inject the dependency inside of its configuration?

Say in rust, you have some struct backing a trait. But your implementation of the trait can also have a variety of options which are parameterized by some other trait. You end up with a generic struct: that is all dependency injection is. Every generic struct in rust is an example of dependency injection.

Instead, dependency injection frameworks help people instantiate large dependency graphs with some lifecycle management. Those I am a bit of the take it or leave it opinion.




I guess I don't typically think of things like Go's context when considering DI, but it serves conceptually the same purpose. My beef is more with the DI frameworks, I suppose.


I honestly think that DI frameworks don't add a lot of value (for me, when I work alone). You annotate some magic on a class or you call that constructor in your composition root. The explicit thing is nicer from my perspective, but most people don't know how to make it modular very well so the DI frameworks pop up to save people the trouble of learning. I prefer DI framework code to singleton spaghetti though, so...


In an OOP codebase, what I usually find is an if or switch with some enum which then calls something along the lines of SomeManager.shared.whatever().

Sorry for being cynical. I can't help it.


You see that in OOP codebases where the authors don't know any compositional patterns. Then the only way to thread logic together is statically, so singletons and the enums like you mention.


Those that don’t know these patterns are way less of a problem than those who know them, know that it would be better to use them, but reject to do so. Because they are effectively lazy and don’t care about other people that have to work with their code in the future.

Unfortunately, there are many of those.

What I often find is that management in organizations rewards these people because they get quick results. The cost to the customer and the team is well hidden until it’s too late.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: