After a longish session pairing with Paul we finally released PicoContainer 1.0 today.
This has been a great journey so far. Paul and I started it right after I moved to London to start working for ThoughtWorks. It all started when I asked Paul one night whether he had heard of Inversion of Control. He got this weird expression on his face when I asked, and I couldn't quite figure out whether he was excited or depressed.
"It's my favourite pattern dood." (Dood pronounced in his native British)
So he got all excited and told me everything about IoC (I didn't have that much of a clue), and about Avalon - a project Paul had been with for a while, but was drifting away from.
My initial reaction (a couple of hours later when Paul didn't have any more breath) was:
"Why does it have to be that complicated?"
We quickly decided to do a spike on a simple piece of code that could do IoC style dependency management via constructors rather than via setters and ugly container lookups from within the components. It's kind of blurry to me how we decided to go for constructors, as we were both drunk when we started TDDing the first lines. I think it was some kind of eureka moment where Paul was thinking about a comment made by Rachel Davies while she was reviewing our colleague Joe Walnes et al's Java Open Source Programming, and I was just being new to this and thought about simplicity. The way I remeber it we unisonely burst out:
"Let's do it with constructors!" (Me left, Paul right)
This was also my first real journey into TDD land. I had known about TDD for a couple of years, but hadn't yet had that epiphany where it fundamentally changed the way I think about code - and religiously follow the practice. I think the first test looked something like this:
public class ContainerTestCase extends junit.framework.TestCase {
public static class Fred {
private final Wilma wilma;
public Fred(Wilma wilma) {
this.wilma = wilma;
}
public Wilma getWilma() {
return wilma;
}
}
public static class Wilma {}
public void testShouldInstantiateClassesAndPassDependencies() {
Container container = new Container();
container.registerComponent(Wilma.class);
container.registerComponent(Fred.class);
Fred fred = (Fred) container.getComponent(Fred.class);
assertNotNull(fred.getWilma());
}
}
This was our first requirement - a container that can instantiate classes and understand what arguments to pass to the constructors. We alternated the keyboard rapidly and made the test pass. This involved some simple reflection logic and was implemented in a couple of classes.
The following days we added more features. Occasionally I would happily try to implement code without writing the test (requirement) first. It always resulted in a slap from Paul and a
"You're doing up-front design again. How do you know whether that is needed or even if it's going to work?"
So I gradually got the hang of TDD, thanks to Paul. (A couple of months later I was greatful for that. I was ruthelessly refactoring the entire codebase to improve the design. That would have been absolutely impossible without the extensive test suite we had built up by then.)
This was back in the days when Codehaus was a small place only hosting a handful of projects. About a week after we started Bob was kind enough to lend us a space for our new little baby, and that's when we named it PicoContainer.
PicoContainer quickly got Jon Tirsén's attention (who I didn't know back then - he has later become a good friend and also a colleague). Jon quickly joined the project and has since been an important contributor. Much of the nice modular design we have today is owed to him. Several other people (Joe Walnes, Chris Stevenson and Mike Hogan to name a few) also helped us in the early days, and Rickard Öberg blogged about it. PicoContainer was now a well-established project. This was late June 2003.
Half a year later my colleague Martin Fowler wrote an article about the concepts behind IoC and PicoContainer, and this is how the term "Dependency Injection" was introduced. (Martin initially coined it "Service Injection", but Rod Johnson refined the term during a Geek Night in the ThoughtWorks offices in London).
Lately we have invited some carefully selected contributors, and we will hopefully invite more in the future.
PicoContainer now has pretty good documentation, we have fixed some 180 feature requests and bugs. It's simple to use, and the jar is no more than 50kb with no external dependencies. There is a .NET and a Ruby port, and more in the pipe. NanoContainer is also an interesting sister project that adds scripted configuration using a multitude of script languages, as well as integration with WebWork, Hibernate and much more. (It's not that well documented yet, but we'll get there).
The best part of this story isn't PicoContainer itself. It is how many people have learned about dependency injection as a way to decouple their code (both internally and from the container itself) and make it testable and mockable. At the end of the day that will bring us code that is easier to maintain. It's your code that counts, and you should be able to choose what container you want to deploy it in - if you need a container at all!
]]>