Re: followup to PhillyETE: dependency injection without the gymnastics (tony morris on monads)

[EirÃkr Ãsheim <stark.fist@gmail.com>]

One problem (IMO) with dependency injection is that you're essentially using "magic" outside of the language itself. That is, you've moved the complexity out of the language/type system and into something else that you have to understand and mentally model. This is a similar criticism that would get applied to using the C preprocessor (or m4, or code generation).

The same objection holds for a lot of reflection- and annotation-based solutions too: they are OK as long as they work, but it can be really confusing to try to figure out what exactly they are doing, and once things go wrong it can be a PITA to diagnose and fix.

I've mostly avoided DI (and other "magic" Java stuff) for these reasons. It's ironic that the conscious lack of powerful abstractions in Java itself created a sort of "black market" of extra-language abstraction to fill the gap (dependency injection would fall into this category).

My 2Â obviously.