[lucasyvas]

I have (and probably will) never voluntarily use a DI framework in any language. There's zero downside to manually doing it. It's explicit, incredibly easy, and you can easily trace backward to see how the program is constructed.

[rochak]

On the same note, I could never really get on with Aspect Oriented Programming. Coming from Java world, I got tired of seeing annotations everywhere and understanding what magic is going on. I like simple and straightforward languages.

[e4e78a06]

You say this now, but I've had to work on 5000 line (literally, 5k lines) classes in legacy code where there are a huge number of dependencies injected manually because the class is doing initialization for a huge number of components. You could argue that this was bad design but I'm sure it didn't start out like that, but just accumulated cruft over time and was too dangerous to refactor. (if prod went down it was at least a few hundred $k down the drain). DI makes it much simpler to wire things like this up without making mistakes like accidentally initializing the wrong class implementation, etc. In polymorphism heavy situations it reduces cognitive complexity a lot.

[csande17]

Dependency Injection frameworks definitely seem like one of those technologies that primarily exists to allow people to get away with bad designs, rather than making it easier to create good designs.

[Rexxar]

5000 lines doesn't tell anything important. I preferred a well organize 5000 lines than 250 files of 20 lines spread randomly in various directories.

If it's 5000 lines and messy it is indeed a problem, but only because it's messy.

[staticassertion]

This is pretty much what I don't get. DI by construction is trivial and has all of the benefits of a DI framework. DI frameworks just let you move some things around, which is mostly confusing.

[ceras]

As someone who's liked using DI frameworks, I'm curious: if you do it manually, as your codebase gets large, doesn't it get harder to "plumb" a new object that needs to get used somewhere at a deep level? This seems like it'd get more unwieldy when refactoring.

I've never worked in a large codebase that did this manually so I'm not sure what it looks like. The large codebases I've seen that don't use DI have used something like a service locator, singletons, or constructed everything where it was needed (and used extensive mocking framework functionality for testing).

[staticassertion]

All object creation is in one place - main. So no, I should never have to go deep anywhere.

[lucasyvas]

This is my take as well. Plus, if you are plumbing something that deep, the odds that your design is total shit is approaching 100%.

Manual DI reveals problems like this way earlier.

DI frameworks, IMO, are some of the most useless around. Solution seeking a problem.