The currently most upvoted answer to a very recent question states that
DI containers are an "enterprise software" pattern, used when the object graph is very large and complex. I suspect that 95% of applications do not require it.
which is something I strongly disagree with. Maybe I've got the terminology wrong, but for me DI framework means just "something wiring my objects together". Am I missing something?
I'm using Guice even for really tiny projects (like 10 classes) in order to simplify them. Sure, it's a 400 kB JAR file, but this isn't what I'd care about. For a small project I hardly ever need any configuration and the only "overhead" is adding the
So I really wonder, what added complexity do DI frameworks cause?
Update addressing the answers
In a 82 class project, I have
- 4 Providers (all of which I'd need also without DI as they're my factories)
- 1 Module containing a single line
- 0 lines XML !!!
That's all. Sure, it's small project, but exactly this was my point. The additional work was a few words rather than lines.
I'm using solely constructor injection in order to get immutable "easygoing" objects. Whenever a new dependency appears, I add a final field, let Lombok's RequiredArgsConstructor take care of the declaration, and let Guice take care of calling it properly.