Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The problem with dependency injection frameworks

jamesshore.com

Post reply on HN
Print view View original

21–30 of 92 posts

Re: The problem with dependency injection frameworks

#21

Post by _gabe_ »

oezi wrote: post #6

Hard disagree. Spending design time on dependency management is time not spend on more import design decisions.

And this is how we end up with spaghetti code. Dependency management is a critical design decision. If you're polluting your global namespace with random classes that get injected everywhere, you end up with a massive tree of intertwined dependencies. Not relying on a DI framework forces you to see that god-awful mess of spaghetti and do something about it or live with the consequences. If you're not thinking about how the major systems in your code interact and where the dependencies flow, then you are missing one of the most important design decisions.

Re: The problem with dependency injection frameworks

#24

Post by pydry »

orobinson wrote: post #14

> I need to know everything that’s going on in my code. I need simple, straightforward function calls. Nothing else! I want to be able to start at main() and trace through the code. I want to look at callers and find where every parameter came from. Reading code is hard enough already. Magic frameworks make it harder. But these frameworks aren't magic. They're just code. Sure it means you have a bit more code to read…

>But these frameworks aren't magic. They're just code.

"Magic" in framework parlance doesnt mean hocus pocus. It just means concealed abstraction.

Re: The problem with dependency injection frameworks

#25

Post by 0xb0565e487 »

niux wrote: post #23
revskill wrote: post #22

At work, all of my function has at most 3 parameters: deps (dependencies), params (for parameters), ctx (for context), which covers all of my use cases, easy to test, debug, isolate.

Can you give an example of a function?

function something(deps, params, ctx) { // put something here }

Re: The problem with dependency injection frameworks

#26

Post by pydry »

I remember the first time I used Spring and I had to debug a traceback that included not a single line of code I had written. It was hell. I almost gave up being a programmer.

Even today I work with half baked frameworks that have the same problem and I hate it.

The difference is that when something like, say, a web framework does this it is buying me something valuable in exchange for the frustrating occasions when the magic fucks up requiring deep dive debugging.

DI frameworks that do this buy you nothing of value except the paternalistic approval of people who dont have the imagination to think beyond unit tests.

Re: The problem with dependency injection frameworks

#28

Post by exabrial »

CDI has a specification, _an extensive specification_, defining the _exact_ behavior of the framework. It is not magic, it’s consistent, predictable, and deterministic. The implementation we use OpenWebBeans, and the alternative implementation Weld, have extensive extensive self tests. I don’t think ever had an issue upgrading over 12 years of using the frameworks.

https://jakarta.ee/specifications/cdi/3.0/jakarta-cdi-spec-3...

I would use a DI or a language that _didn’t_ have a spec or you would experience the things in the two articles people fear.

Post reply on HN