Del.icio.usly De.lirio.us Perl Deja Vu with new Groovy Syntax
Mar 31

IoC: One of those things you need to try, to get it

Lightweight Containers, Tech Add comments

Everyone is chiming in on Cedric’s post claiming that he doesn’t get IoC.

I sometimes feel that the IoC crowd expects to explain IoC and have people say *a ha!*, and suddenly stand back with halo’s as they see the amazing benefits.

In reality, I always find IoC to be one of those ideas which seems simple, almost TOO simple, and hard to REALLY get.

The only way to get it in my opinion is to live it.

There are a lot of technologies like this. You can’t really understand what it does to YOU the programmer, until you do some work with it. E.g., using a real ORM, playing with Ruby/Lisp/Haskell, etc etc.

IoC, to me, gives me a way to help me write clean code. Nice units to test easily, forcing me to design to interfaces (which I tried to do before hand anyway, and which Cedric does (which is another reason why it doesn’t seem like a big deal sometimes).

I never want to see a lookup("foo"). As soon as I do I get the jibblies. What if foo isn’t there? What exceptions do I need to handle with foo?

So, for me, IoC is both a big deal, and a small deal. I don’t really think about it anymore. It is just part of the system, part of the pattern of writing code. It is used to help test, be agile, and all the cliches.

But, you won’t ‘get it’ until you just do some serious work using it… and then you won’t even think “oh I get it”, you will just be doing it.

7 Responses to “IoC: One of those things you need to try, to get it”

  1. Dale Asberry Says:

    Hmmm, maybe you could say this about AOP and Jini too ;-)

  2. James Strachan Says:

    Agreed – it reminds me a bit of OO. It takes a while to get it and its also hard to explain to someone who doesn’t get it, what it is.

    e.g. coming from a background of C with structs and function pointers, a C developer might not really get OO – thinking in terms of C structs and functions, they might not see what the big deal is with OO.

    Similarly coming from a J2EE, look things up in JNDI / EJB Context kind of mindset, I think its hard for folks to get the point of IoC unless they just do alot of it – then the penny drops.

  3. Jason Carreira Says:

    Hmm… I have to disagree.

    A light suddenly came on for me as I was sitting in the DMV waiting to renew my license and reviewing some chapters from the “Opensource Programming in Java” book by Mike Cannon-Brookes, Patrick Lightbody, Joe Walnes, and Ara Abrahamian. The discussion of IoC there suddenly opened up a world of possibilities…

    It’s been tough for me to see posts from Joe ever since without seeing a little halo ;-)

  4. Eelco Says:

    Hmmm. I don’t know. I have been doing the IoC thing for about four years now (based on a home grown framework at first, before the IoC term showed up), but lately try to not depend on it too much.

    The pattern itself is fine. But the way of composing systems with it IMO distracts you from writing good OO code. Instead of thinking about what makes a good object, you (at least I and a lot of juniors I’ve seen) go into the functionality mode as soon as you’re thinking in modules with dependencies.

    The pattern of injecting dependencies is really good. Building your whole system on that pattern alone, declared in huge XML files is less so imo.

  5. Hani Suleiman Says:

    Nope!

    Isn’t it possible that he fully understands and sees IoC, and decides that it really isn’t such a big deal?

    Interesting in the list of things you mentioned is the omission, the things that one looks at, gets, and decided it’s not the best thing since sliced bread.

    I think the idea that IoC is another revolution or a big jump is frankly indicative of a fairly warmed imagination (yesyes, you know me and my exagerations!)

    It’s nothing more than a new tool in the toolbox. Sometimes it’s appropriate, often it isn’t.

    Oh and the lookup example is bogus too. Imagine JNDI without checked exceptions. Ultimately you’re still relying on *something* to have successfully created your service and put it somewhere whereby you can get at it. Said mechanism is equally susceptible to disasters; misconfigured JNDI == failed autowiring by spring. Error in service creation can cause an NPE in both cases, if you’re not careful.

  6. Dion Says:

    Hani -

    I still prefer autowiring to lookup(). Failed spring config will fail a lot faster. And having the lookup key as a String?

    Of course you are magically saved from anything.

    I think I was trying to say that IoC *isn’t* an amazing revelation. Of course it is a tool in the toolbox. But if you say “i don’t get it”, then to me it means that you don’t HAVE the tool in your toolbox.

    Dion

  7. hand and foot fungus Says:

    subj to arouse interest

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'