If I was to summarize the evolution of my thoughts regarding dependency injection (DI)...
What is this dependency injection thing everybody is so excited about?
Oh, you mean decoupling interface and implementation--I like that.
So what do these DI frameworks bring to the table?
Less boilerplate code--that's good.
But now I have a dependency on a framework--that kind of sucks.
Now I have all this hairy configuration in some XML file--that really sucks.
Annotations are pretty cool. Still seems like be can do better.
Well, it's 2009 and maybe we have done better. Consider how the Scala compiler is composed
While it's not called dependency injection per se the net result is the same: we're able to abstract the required services. Tomorrow, if we wanted to log symbols we'd just implement a new LogSymbols and use mixin composition to get our new behavior. Or we can stub/mock out Symbols during testing. All without boilerplate code, messy configuration or clumsy bindings. And everything is type-safe. Pretty cool initial impression.
You can read more about how Scala does it in "Scalable Component Abstractions." Some of stuff is a bit foreign unless you have a strong functional background or really into type systems, but the compiler case study helps.
Comments