I guess my main problem with a dependency injection framework would be, why do you need a framework besides a class system and import statements to do dependency injection?
The problem with dependency injection frameworks
81–90 of 92 posts
Re: The problem with dependency injection frameworks
#82> “This implementation is difficult to unit test.” Horsepucky. You can still have dependency injection without a framework. Just make a constructor that takes the dependency as an optional parameter. Done. Applause. Early lunch. Ok so it's specifically the frameworks that's disliked. > Furthermore, dependency injection frameworks encourage you to think in terms of globals. That’s what they inject! A single, globally-…
Try Dagger, it generates DI code during build. So it's kinda hard code, but the framework does it for you. So the startup is much faster, and easier for JIT compiler to reason (no reflection)
I've already quit using Spring/Boot for other reasons (Hibernate/JPA) but good to know.
Re: The problem with dependency injection frameworks
#83Earlier quoted context omitted.
> I think anyone arguing for frameworks should spend some time making a serious attempt at frameworkless dependency injection. The frameworks are really doing so little for you, at occasionally horrendous cost. That is what I did, and decided a DI framework was much better. If you have a single scope, like singletons, its pretty easy to do the wiring manually. If not, then you see very quickly that your scope managem…
Passing a single "context" struct/class/whatever into everything basically solves DI. I can see using a framework for this, but it doesn't seem necessary.
That is DI. The difference is that you're using a registry or container object as your DI repository.
Re: The problem with dependency injection frameworks
#84The Dependency injection pattern is just not that great in general. There are alternative patterns that are better. It is not a problem with frameworks. Think about it. If the pattern was good, then a good framework must exist. If no good framework exists then logically it is very likely that Something is wrong with the Pattern itself. Anyway the reason why DI is bad is because it's too complex. In your program, you…
DI isn't what you think it is. What you're describing is the old imperative vs OOP debate.
No. I know what DI is. The debate is similar to imperative vs. OOP. But this is not exactly what I am referring to. Literally look at the second example, it's DI over and over and over again.
I am referring to DI 100%. Function composition works better and is a replacement for DI. You're the one that isn't getting it.
Either way, imperative programming and OOP are orthogonal concepts. There never really was an argument about imperative vs. OOP.
Additionally function composition is an FP concept. I'm not promoting FP over OOP here... far from it, I am simply saying that specifically for DI, you can borrow a pattern from FP and use it in place of DI because function composition is a much better pattern.
Re: The problem with dependency injection frameworks
#85Earlier quoted context omitted.
Before « move fast and break things », there used to be a thing called « documentation ». It included things like « design documents » and would ensure people were able to quickly understand a piece of code.
Maybe, maybe there was. In my experience when someone talks about how much better "it" used to be and how low we've all sunk these days, "it" never really was as good as they're saying. But maybe. In any case though I live and work now, when companies who prioritize and support the work of creating and maintaining thorough reliable documentation are rare. So I plan my work for situations I can expect to encounter now…
documentation is an ongoing process. You document your code before, during, and after you write it.
I don't understand how one can maintain a piece of code without it for more than a few months, even as a single person. One always forget things.
i also don't understand how one can design a piece of architecture without diagrams and maps and all kind of design documents. They are used both for clarity, as well as to discuss between team members. Then keeping them somewhere is also part of documenting the code.
Re: The problem with dependency injection frameworks
#86Earlier quoted context omitted.
Until you want to add an argument to that constructor and find yourself modifying lots of files just to update that call everywhere. Or need a value from the application config, and have to patch the configuration instance through, several levels of classes deep. After wasting a day or two with those shenanigans, you’ll gladly take the DI framework, which makes both scenarios a single-line, 10 second change.
Or just create two versions of the constructor - one that takes the arg, and one that doesn't. The one that doesn't does whatever magic you were planning for the DI, does that, then calls the constructor with the arg.
Planning magic isn't necessary! What if your class requires a new dependency?
Re: The problem with dependency injection frameworks
#87The alternative of wiring up your own dependencies is pretty trivial and I really prefer it. Martin Fowler calls it a Service Locator, https://martinfowler.com/articles/injection.html#UsingAServi...
I would prefer manual DI:
https://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/
Re: The problem with dependency injection frameworks
#88Dependency Injection is just a fancy, obfuscating, name for global variables.
global variables is dependency injection via global context. This is just one flavour
Re: The problem with dependency injection frameworks
#89Earlier quoted context omitted.
Maybe, maybe there was. In my experience when someone talks about how much better "it" used to be and how low we've all sunk these days, "it" never really was as good as they're saying. But maybe. In any case though I live and work now, when companies who prioritize and support the work of creating and maintaining thorough reliable documentation are rare. So I plan my work for situations I can expect to encounter now…
documentation is an ongoing process. You document your code before, during, and after you write it. I don't understand how one can maintain a piece of code without it for more than a few months, even as a single person. One always forget things. i also don't understand how one can design a piece of architecture without diagrams and maps and all kind of design documents. They are used both for clarity, as well as to d…
It's not that I don't see it this way or don't value those things. It's that companies I work for haven't valued them. Doing this won't positively affect my evaluations, but taking time away from other work to do it well, will negatively affect them.
If the company would prefer to pay the long-term cost of having no or poor documentation than to pay me to do it now, that's up to them I guess. I take my own notes and go on with my life.
Re: The problem with dependency injection frameworks
#90Earlier quoted context omitted.
Passing a single "context" struct/class/whatever into everything basically solves DI. I can see using a framework for this, but it doesn't seem necessary.
That is DI. The difference is that you're using a registry or container object as your DI repository.
I know. DI is solved easily without a framework. Idk why there's even a word for DI; never occurred to me how else you're supposed to code (globals?).