rebelutionary / 2.0

The Great Inversion of Control Debate / 2003 May 12

There's a debate raging (ok, raging is maybe a bit strong) on the opensymphony-webwork mailing list about the new Inversion of Control functionality. It should be on the archives soon enough.

Personally I like IoC, it makes things feel clean and neat. I thought I'd post my mailing list post here too so the discussion might move from mailing list to blogosphere - hopefully spurring further discussion.

Post:

I have to agree that it's not clearly evident what the benefits are, but from tinkering with IoC (particularly the stuff in Xwork - which is kinda why it's IN Xwork :)) it just seems to make nicer code.

Disclaimer: I'll say up front that a LOT of this is subjective and each person will have their own opinions. If you don't like IoC or prefer Registry's, that's fine too - just ignore the IoC stuff in Xwork and move along as normal :)

Patrick and I are part of a 4 author book team writing a tome at the moment, and one of our core themes is IoC - so we've debated this issue ad nauseum. We decided to include it because the authors like the pattern, but we have also discussed alternatives for those who don't like it.

Let me try to do a mental dump of some of the benefits:

The testability is a huge issue for us, but I think that depends on how 'test driven' your development methodology is. Not having to worry about preconfiguring registries when testing your classes makes them much easier to test in isolation.

Basically - it makes testing easier, and the component boundaries clearer.

Here are some more thoughts from an email which might help more: (Joe is a lot more lucid with his descriptions than my hackish attempts at the English language) :

• IoC is a 'design push' (like tdd and mocks). While it's easy to bypass, it actually makes you more aware of how your components are coupled together.
• A component describes itself. When you instantiate a component, you can easily determine what dependencies it requires without looking at the source or using trial and error.
• Dependencies can be discovered easily using reflection. This has many benefits ranging from diagram generation to runtime optimization (by determining in advance which components will be needed to fufill a request and preparing them asyncronously, for example).
• Avoids the super-uber-mega-factory pattern where all the components of the app are held together by a single class that is directly tied back to other domain specific classes, making it hard to 'just use that one class'.
• Adheres to Law of Demeter. Some people think this is silly, but in practise I've found it works much better. Each class is coupled to only what it actually uses (and it should never use too much) and no more. This encourages smaller responsibility specific classes which leads to cleaner design.
• Allows context to be isolated and explicitly passed around. ThreadLocals may be ok in a web-app, but they aren't well suited for high concurrency async applications (such as apps message driven apps or things using seda architecture).

Really, none of these things are that convincing, but since switching from a registry style to IoC style it has really increased visibility of things like higher-level design, decoupling of components and seperation ofconcerns/responsibilities. Although it's a bit more short term effort to add a setter, the long term effort pays off. This design visibility is a good thing.

IoC is just a small part of this process. Avalon has been pushing this stuff for a long time - they have some info on the other patterns that complement it here (a bit dated).

It is a hard thing to describe. It took ages to sink in for me with Paul harping on about it. I recall that for a while, none of you guys were convinced either. What made you change your minds? Why is it so cool?

For me it was this...

Writing a test one day:

CarShowRoom showRoom = new CarShowRoom();
Car car = showRoom.suggestSuitableCar();
assertEquals("red", car.getColor());

(me: hmmm... this CarShowRoom class will need access to the UserProfile to get the user's prefferered color).
UserProfiler profile = new UserProfile();
profile.setPreferredColor("red");

(me: now the profile needs to passed in to the show room... we do that by substituting the instance in the service manager)
UserProfiler profile = new UserProfile();
...
ServiceManager.add(UserProfiler.class, profile);
CarShowRoom showRoom = new CarShowRoom();
...

(my pair: dude, that sucks. Surely you want to pass the profile to the showroom - why add another class and level of indirection?)(grabs the keyboard)

UserProfiler profile = new UserProfile();
...
CarShowRoom showRoom = new CarShowRoom();
showRoom.setProfile(profile);
...

(me: uhmm.. yeah, actually, that feels 'right'.)
(karma++)

I hope this helps!

Again if you disagree or don't like IoC - that's fine too - reread the disclaimer of this post before hitting 'Send' on your flame :)

Comments