Ummm… no, but I still wouldn’t go overboard using it.
Ok, all jokes aside. Dependency injection frameworks are invaluable at times but they introduce variability into your code that can bring problems too. Anyone into functional programming will tell you that avoiding excess state creates simpler programs. Fewer “moving parts” can promote code that is more reliable and contains less faults.
With dependency injection you introduce additional factors into the program state. Looking at an instance variable, dependency injection makes it that much harder to know exactly what it is, and how and when it got there. Mix in an application life cycle, for example Android’s, where you may get paused/resumed at will, and you’ve a whole slew of new edge cases to consider. Over time, with instances controlled by injection, your context may change and even become inconsistence over time.
Again, DI is an invaluable tool that I use, but if code is gratuitously littered with @Inject, @Assisted etc. I consider that a very bad code smell. When you are trying to trace the behavior of a piece of code you’re going to find it hard to pin down exactly what things are and how they got there. Not good.