Home > View Post

The Awesome Power of IoC Part II

Yesterday I introduced a small series of posts on using Castle's Windsor Container to provide some Dependency Injection. If you haven't already read that post, go there now: The Awesome Power of Ioc Part I. Then come back here.

As you may recall (or you've just read) the last post's code seemed to do quite a lot to achieve only a little. But let's extend the example. Imagine our SnareDrum class has too much to do, and we decide to desolve responsibility to some other classes. In particular, it isn't really the drum that gets hit, it's the skin, right? (I don't know much about drums but I think that's about right). So, the SnareDrum has a dependency on some kind of skin...

using System;

public interface IDrumSkin
    void Whack();
    int Tension {get; set;}

We need to change our SnareDrum class to use the new IDrumSkin service, and we go for a bit of constructor injection because we know that's nice and easy to unit test.

using System;

namespace Tjoc.MusicalIoc
    public class SnareDrum : IPercussion
        private IDrumSkin _skin;
        public SnareDrum(IDrumSkin skin)
            _skin = skin;
        public void Hit()

We also need a concrete implementation of IDrumSkin that we can use. I've called it SnareSkin and notice that in my world, the more tension the longer the bang!

using System;

namespace Tjoc.MusicalIoc
    public class SnareSkin : IDrumSkin
        public SnareSkin(int tension)
            _tension = tension;

        private int _tension;

        public string Whack()
            return "B" + new string('a', _tension) + "ng!";

        public int Tension
            get { return _tension; }
            set { _tension = value; }

Finally we need to tell the Windsor Container about the new service by adding another component to the config. However, you may have noticed that we have a small problem: Neither SnareSkin or SnareDrum have default constructors.

This is where the Windsor Container really starts to rock.

For the SnareSkin we can actually specify the tension parameter on the constructor in the configuration:

<component id="snareSkin"
    service="Tjoc.MusicalIoc.IDrumSkin, Tjoc.MusicalIoc"
    type="Tjoc.MusicalIoc.SnareSkin, Tjoc.MusicalIoc">

So lets run the program and see what happens.


Great! But how did the container create an instance of the SnareDrum class, since we changed it to require an implementation of IDrumSkin for construction?

The WindsorContainer has a configured service for IDrumSkin and it created an instance and called the appropriate constructor for you!


Next we'll look at adding another dependency just to demonstrate that you really can go to 'n' levels with this.

UPDATE: Part III now available.

Tags: .NET

Josh Post By Josh Twist
2:46 AM
21 Sep 2006

» Next Post: USB should be enough for anybody
« Previous Post: The Awesome Power of IoC

Comments are closed for this post.

Posted by Brian @ 21 Sep 2006 7:08 PM
You know I guess I'm one of those who just doesn't see the hype around it still. I always enjoy your articles and I know you know what you're doing, so I'm kind of blindly following along right now.

I guess my big 'blah' feeling on the hole IoC/Dependancy Injection bandwagon is that you know it's nice for school and the wow factor stuff to people who have only created objects using hard coding - and yes, I agree that you occassionally do need some form of it - security is a good example. I've also even had an opportunity where we were switching from AS400 to Oracle and half way through started going to DB2 (and then went back to AS400) - so having our data provider use constructor injection was nice; but how often does that happen? If it was a shop who had it's stuff together it probably wouldn't of happened in the first place and wouldn't of been designed that way.

Anyway when we were doing this we didn't even think of IoC or Dependancy Injection as a formal pattern (I didn't even know about it at the time) - we just needed to be able to swap the data access components we were using without having to recompile because we knew huge database changes were being made - so when a Java friend of mine told me that it was a pattern I was like - okay - I just considering it programming smartly. I think people have been doing things like this since way back probably - it just has a name now...and a lot of hype.

I've also worked on other projects where you have nothing hard coded (it's very rare to see a 'new' statement) and everything is in these 1000+ lines config files...which is frustrating; nothing is ever going to change in these applications - no one is going to write other types that they could swap the current ones out with - in fact, for some of these apps any changes that would be made would require recompiling anyway because of the other coupling created. It's just extra moving parts and a lot more time was spent creating this level of indirection with no measurable benifits since the time it was created...not just diminishing returns; no returns at all in this particular case; in fact I'd say with the cost of maintnance and debugging its had a negative return...and yes this is an extreme.

So I guess my lack of enthusiasm this go around is because there's always all this hype around one Fowler pattern or another - and the man's a genius, no doubt; as are the GoF and 3 Amigos, and all the other legends in our industry. There's also always hype from something 'new' out of Redmond or some other market that has everyone's attention. But all this hype results in a lot of 'silver bullet mentality' in our community and a 'this is cool let's use it' without having a need for it...over-architected can be coined to several projects I've worked on...the KISS principal seems to me missing from the vocabulary of the modern programmer.

But as I said, I'm not a smart guy, I read your articles because I know you are, so it's quite possible that I'm missing something and the light bulb just hasn't gone off yet around the whole thing and mayber there's more to it than I realize - wouldn't be the first time, that's for sure; so don't take me wrong.

Anyway, thanks for your Posts, your always a great help, and when folks like me don't 'get it', just keep with it...I don't learn as fast as I use to.

Posted by Josh @ 22 Sep 2006 9:28 AM
Hi Brian,

Thanks for taking time to reply in such depth. I'll try and answer some of your points, and agree with the rest in the next part.

Drop me a line with the url of your blog if you have one so I can give you a link.

© 2005 - 2021 Josh Twist - All Rights Reserved.