Spent a couple of hours this afternoon getting to know the Castle Windsor IoC container again.

I ran through the sample as a refresher and then converted a small app I had lying around to use loosely coupled services/components.

Talk about simple, easy and powerful.  I've read enough about this thing to know how it works and played with it briefly in the past, but the latest release adds support for generics and makes it so much easier to use than before (not that it was hard). 

The effort involved in converting an existing "hard wired" app to be one using loosely coupled services connected at runtime via the plumbing magic of an IoC container is obviously dependent on the current state of the app, but even so switching my app across was only a matter of adding a few lines of code and doing a bit of refactoring.

For instance let's say I have an app that parses some input, I could instantiate parsing and messaging services like this:

IWindsorContainer container = new WindsorContainer();
container.AddComponent<IMessageDisplay, ConsoleMessageDisplay>("console.display");
container.AddComponent<IInputParser, InputParser>("inputparser");

If I wanted my parser to display messages to the user when there was a problem I'd normally have to wire up the connection between the classes myself, but now I don't need to.  All I need to do is have a constructor for the parser like so:

private IMessageDisplay display;
public InputParser(IMessageDisplay display)
{
  this.display = display;
}

and the Windsor container takes care of injecting the appropriate IMessageDisplay class for me.

The container looks after the lifestyle (singleton, pooling, instance-per-request, etc) of each service as well and the lifecycle (instantiation and disposal) of each object.

All that nasty plumbing that we typically have to do is removed and our application becomes so much easier to maintain.

Why do we still insist on writing code in such a tightly coupled manner?