3 ms·

> I get the benefits of dependency injection I don't. I think dependency injection encourages thoughtless code. It makes it easier to "magically" make your de

by _gabe_ 3y ago

> I get the benefits of dependency injection I don't. I think dependency injection encourages thoughtless code. It makes it easier to "magically" make your dependencies appear wherever you want them without having to think about anything except the lifetime. Once you're project gets significantly complex, it becomes very difficult to understand what your web of dependencies is actually doing, and to comprehend how the lifetimes all interact. Screw dependency injection. Do it the "hard way" and make the pain points ridiculously clear so that you can see where the flaws in your architecture are revealing themselves.

aakresearch 3y ago
I am with you. The analogy I came up with is "map layers". Usually on a geographical map the features are drawn using contours, colours and accompanying names. Such map is, certainly, not a "territory" but is a good representation and easy to work with. Using (capital DI!) Dependency Injection is like a having a map "lobotomized", split into layers where you can never see them together. You either see contours devoid of names, or names hanging in the void. Bonus point if names don't even follow the contours. For any non-trivial number of classes/concepts my brain explodes. Another bonus point when DI is used for some deep-context "dependencies". Hey, I need a HttpClient object here, to post something somewhere. Why, instead of having a URL and instantiating my client right here, I need to dig through the sands of DI bindings to find a way to "configure" HttpClient for this particular instance? Well, I understand theoretical reasons, but in practice they never make sense and only add pain. Another bonus point for run-time binding errors. Those sometimes slip through even when there is a "test" in the CI/CD suite for that. I think dependency injection has its place, but as used presently it resembles a cargo-cult.

by _gabe_ 3y ago

aakresearch 3y ago

I am with you. The analogy I came up with is "map layers". Usually on a geographical map the features are drawn using contours, colours and accompanying names. Such map is, certainly, not a "territory" but is a good representation and easy to work with. Using (capital DI!) Dependency Injection is like a having a map "lobotomized", split into layers where you can never see them together. You either see contours devoid of names, or names hanging in the void. Bonus point if names don't even follow the contours. For any non-trivial number of classes/concepts my brain explodes. Another bonus point when DI is used for some deep-context "dependencies". Hey, I need a HttpClient object here, to post something somewhere. Why, instead of having a URL and instantiating my client right here, I need to dig through the sands of DI bindings to find a way to "configure" HttpClient for this particular instance? Well, I understand theoretical reasons, but in practice they never make sense and only add pain. Another bonus point for run-time binding errors. Those sometimes slip through even when there is a "test" in the CI/CD suite for that. I think dependency injection has its place, but as used presently it resembles a cargo-cult.