Hacker News Reader

Comment by thiht | Hacker News Reader

No 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.

View on HN

> 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.

This 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

Eh, 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.

"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.

Ya 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.

I 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.

The 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.

How 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?

Exactly, 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.

Reply on news.ycombinator.com