The currently most upvoted answer to a very recent question states thatDI 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 @Inject annotation.So I really wonder, what added complexity do DI frameworks cause?Update addressing the answersIn a 82 class project, I have32 @Inject annotations15 @Singleton and 1 @ProvidedBy annotations4 Providers (all of which I'd need also without DI as they're my factories)1 Module containing a single line0 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.
What complexity do DI frameworks add?
java;frameworks;dependency injection;google guice