Friday, January 7, 2011

Inversion of Control: It’s All About Decoupling

I've been using Dependency Injection and Inversion of Control for a few years now and have always wondered why there is such resistance to the concept. I've heard the argument that it seems too complex and on a not-so-recent Dot Net Rocks episode, Richard Campbell was concerned that it would make debugging more difficult. To me, Dependency Injection and Inversion of Control are just fancy words for a technique designed to reduce the coupling in your system.

Coupling is one of those terms that everyone knows, but few pay much attention to on a daily basis. I can remember an exam I wrote for a second year Computer Science course that had the following multiple choice question on it:

Object-oriented code should exhibit these characteristics:

a) High coupling, high cohesion
b) Low coupling, high cohesion
c) High coupling, low cohesion
d) Low coupling, low cohesion

I knew the answer right away, but thinking back on it, I couldn't have gone into much more detail about what those terms actually meant, or more importantly, how to apply the principles to code. I’ve found that coupling and cohesion are concepts that most people take a long time to apply at anything more than an elementary level.

At one place where I used to work, the development team completed 360 degree evaluations of the each other. One of the characteristics that we evaluated each other on was that we wrote “quality object-oriented code that displayed a low level of coupling and a high level of cohesion.” Vague I know, but what was most interesting about it was that the developers who wrote the poorest code in this regard scored themselves the highest, and the developers who wrote the best code, scored themselves the lowest. I interpreted this to mean that the developers who fully understood what it meant to write loosely coupled code were able to remove much of the coupling from their code, but were also keenly aware of the coupling that they left behind.

The argument that IoC makes debugging more difficult doesn’t hold any weight to me.  The argument is that you don’t know exactly which implementation is being called when a method is called because the call is to an interface or an abstract class and not a concrete dependency.  Now listen up people, cause I’m going to let you in on a little secret, THAT’S CALLED LOW COUPLING!  You’re only coupled to the interface, not the implementation, that’s what object orientation is all about!

So the next time someone tries to argue against IoC because it’s too complicated, just remind them about the foundations of object-oriented programming.

1 comment:

Chris Nicola said...

Honestly I hate to say this about Richard Campbell as I've met him and he is a genuinely smart and insightful guy, but if RC and DNR are suggesting using IoC could in any way hamper debugging people really should reconsider trusting any advice they hear on that show. I say that with all due respect because I think what they have created is a good thing, but spouting off about techniques and frameworks one obviously has never used is terribly wrong.

I have actually seen a few blog posts recently, arguing that IoC may not really be as good as we think it is and these have really made me start to think about it, but these arguments are really targeted for people who have used and have at least some understanding of IoC and how it works.

I would advise absolutely anyone (well except people working in dynamic languages) to learn IoC. You owe it to yourself to understand it regardless of any arguments about it (most software practices, tools and frameworks have some level of debate going on) and then decide for yourself when, where and why to use it. I missed the show, but I hope RC and DnR still encouraged listeners to learn it for themselves.