Howard Lewis Ship has added an IoC Overview document to the Tapestry IoC project. It’s goal is an important one, helping developers “get” IoC.

For me, “getting” IoC was a big event. It happened to me in early 2004 when I was working on a workflow engine for a large back office application for a bank. A friend of mine told me I should check out HiveMind (the predecessor to Tapestry IoC). Using it, I found I was able to develop more sophisticated, more testable code with less grunt work. The dots between object oriented design and application assembly were connected elegantly.

The document mentions that style of code that works best when using an IoC container:

When thinking in terms of IoC, small is beautiful. What does that mean? It means small classes and small methods are easier to code than large ones. At one extreme, we have servlets circa 1997 (and Visual Basic before that) with methods a thousand lines long, and no distinction between business logic and view logic. Everything mixed together into an untestable jumble.

At the other extreme is IoC: small objects, each with a specific purpose, collaborating with other small objects.

Using unit tests, in collaboration with tools such as EasyMock, you can have a code base that is easy to maintain, easy to extend, and easy to test. And by factoring out a lot of plumbing code, your code base will not only be easier to work with, it will be smaller.

The document ends with the concept that IoC does for object creation what garbage collection does for object destruction: takes it out of your hands and does it better (here is an older blog post on that same topic). I think the Guice project captures this concept the best when describing their @Inject annotation, calling it “the new new“.