{ tinou bao }

Scalable Component Abstractions

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.

The Language Quadrant

On the recommendation of a fellow blogger I started reading Types and Programming Languages by Professor Benjamin C. Pierce.  It's probably not very practical for the average developer; when was the last time I needed a thorough understanding of the untyped lambda calculus? But it's always good to think beyond the immediate.  Here's something interesting to think about, the language quadrant:

	Statically Checked	Dynamically Checked
Safe	ML, Haskell, Java, etc.	Lisp, Scheme, Perl, Postscript, etc.
Unsafe	C, C++, etc.

Languages provides abstractions against low level machine services (memory, I/O, etc.).  Safe languages prevent you from mucking around with these abstractions, allowing you to program abstractly.  An array is a memory abstraction; in a safe language you just need to worry about the array abstraction whereas in an unsafe language you need to further worry about all the other ways memory can be addressed.

The other axis divides languages into statically checked and dynamically checked.  Statically checked languages perform type checking at compile time whereas dynamically checked languages perform type checking at runtime.  While this is obvious, it is important to remember that types exists in both cases.  Dynamically checked languages may infer types at runtime but there still exists types.  On the other hand, untyped languages have no concept of types altogether.  With assembly languages you can perform any operation on any data, since everything is just a bunch of bits.

The fourth quadrant is empty because the additional cost to perform checks on the additional operations is little; so if you're going to enforce safety for most operations then you might as well do it for all operations.

Dependency Injection is Broken

Beside adding support for closures to Java 7, I propose adding support for runtime interface and abstract class reification.  Well, I propose that someone who actually knows what they're talking about propose such a mechanism. 

Background: Earlier today I was reading a blog about the worthlessness of constructors.  Frankly, I didn't really get the point of the post, but the title was catchy.  Jeremy mentioned something about dependency injection (DI), one of my favorite topics, having written at length about how crappy Spring is (it's really not, and I hope the Spring guys didn't take offense to it--like Jeremy, I tend to be hyperbolic in my praise and criticism).

The problem I've always had with DI frameworks, be it Spring or Guice, is they create this nasty dependency tree.  If you don't want to use GlobalApplicationContext.getBean() or Injector.getInstance() then you'll need to inject all your dependencies at the root.  It annoys the crap out of me, but I suppose there's just no way around it...

Except if the language had a mechanism to realize interfaces and abstract classes at runtime, either built-in or through some extension. 

I want to be able to do something like this

interface MovieFinder {...}

...
MovieFinder mf = realize MovieFinder();
List<Movie> movies = mf.findAll("Scarlet Johansson");
...

and have the language realize the MovieFinder interface for me (at runtime).  It could be a DBMovieFinder, or maybe a MockMovieFinder for testing purposes.  "realize" is just like "new" except we let the runtime figure out what concrete implementation(s) reifies the interface or abstract class.  The fundamental problem with all dependency injection tools is they are trying to do what  language should be doing (instantiating objects that implement some interface).

As I mentioned earlier, I don't think the Java language should have this built-in, because it is a rather specific use case; but Java might have some sort of extension mechanism so that it appears built-in to the average programmer. 

I'm sure there are many issues with such a mechanism, but I don't think I'm too off base.   Gilad Bracha writes,

The root of the problem DIFs address is that mainstream languages provide inadequate mechanisms to abstract over classes.

And apparently the creator of Guice agrees,

Ideally, the language itself would provide most of the same features, but until such a language comes along, we have Guice.

It's 2008, we've landed a man on the moon, and I'm still clunking around with DI tools!