5 ms·
Or don’t use a DI framework, and DI just becomes a fancy name for "creating instances" and "passing parameters". That’s what we do in Go and there’s no way I wo
by thiht 1y ago
Or don’t use a DI framework, and DI just becomes a fancy name for "creating instances" and "passing parameters". That’s what we do in Go and there’s no way I would EVER use a DI framework again. I’d rather be unemployed than work with Spring.
- surgical_fire 1y ago[flagged]
- thiht 1y agoNo need to be aggressive, I just disagree that DI frameworks streamline anything, they just make things more opaque and hard to trace. > will be a very annoying thing to maintain as soon as you change the constructor of something widely used in your project to accept a new parameter. That for example is just not true. You add a new parameter to inject and it breaks the injection points? Yeah that’s expected, and suitable. I want to know where my changes have any impact, that’s the point of typing things. A lot of things deemed "more maintainable" really aren’t. Never has a DI framework made anything simpler.
- surgical_fire 1y ago> That for example is just not true. You add a new parameter to inject and it breaks the injection points? Perhaps you never worked in a sufficiently large codebase? It is very annoying when you need to add a dependency and suddenly you have to touch 50+ injection points because that thing is widely used. Been there, done that, and by God I wished I had Dagger or Spring or anything really to lend me a hand. DI frameworks are a tool like any other. When properly used in the correct context they can be helpful.
- culturedsystems 1y ago"It is very annoying when you need to add a dependency and suddenly you have to touch 50+ injection points because that thing is widely used" You don't have to update the injection points, because the injection points don't know the concrete details of what's being injected. That's literally the whole point of dependency injection. Edited to add: Say you have a class A, and this is a dependency of classes B, C, etc. Using dependency injection, classes B and C are passed instances of A, they don't construct it themselves. So if you add a dependency to A, you have to change the place that constructs A, of course, but you don't have to change B and C, because they have nothing to do with the construction of A.
- cornel_io 1y agoI think you're being downvoted because you're agreeing with the post you're quoting, but arguing as if they're wrong: the example in question was there to show how DI can be useful, so there's nothing to argue against.
- therealdrag0 1y agoYa very confused by this. Either the change is to the constructor of the object being injected, in which case there is no difference either way, or the change is to the constructor receiving the injection, in which case there’s no difference either way.
- layer8 1y agoThis is the only reason why DI frameworks exist. However, this issue can be largely avoided by working with configuration objects (parameter objects [0]) from the start, that get passed around. Then you only need to apply the change in a small number of parameter-object classes, if not just a single one. [0] https://wiki.c2.com/?ParameterObject https://wiki.c2.com/?ParameterObject
- jcelerier 1y agoEh, having built a whole codebase around these configuration objects I really regret not going for more traditional DI IoC container. It's thousands over thousands of additional parameters passed all over the place when creating objects just for the sake of saving five minutes of explanation to newcomers.
- baq 1y agoThe one thing DI frameworks unarguably and decisively solve by design (if accidentally, but it doesn’t matter) is control over static initialization. I’d say you haven’t truly lived if your C++ didn’t crash before calling main(), but it helps in large JS and Python projects just the same.
- layer8 1y agoHow do they solve that? If constructors require certain parameters, someone has to pass them. If it’s not a top-level object, the instantiating code will pass it and have a corresponding constructor or method parameter itself. At the top level, main() or equivalent will pass the parameter. Where is the problem?
- baq 1y agoExactly, there is no problem when you do it this way and DI frameworks force you to. The problem when you don't do it this way is when you depend on order of initialization in a way you are not aware of until it breaks, and it breaks in all kinds of interesting ways.
- babyent 1y agoChill dawg
- tomhow 1y agoBe kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." Please don't fulminate. Please don't sneer, including at the rest of the community. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- Gibbon1 1y agoI'm a small brained primate but when I get down to what dependency injection is doing it's like my firmware written in C setting a couple of function pointers in a radio handler's struct to tell it which SPI bus and DIO's to use. Which seems trivially okay.
- jen20 1y agoMaybe you could even use a different handler in tests!? Shocking that you can do this without using an IoC container and a thousand lines of YAML! /sarcasm (in case anyone doubted it).