<= Home

Inversion of Control Pattern vs Dependency Inversion Principle

Posted about over 2 years ago

I was talking to a former associate I used to work with about a new “Inversion of Control” (IOC) container I had been playing with. He is a big OOP enthusiast but had not heard of IoC before. He later emailed me that after his research that Inversion of Control was nothing new and that it was formulated a long time ago in the “Dependency Inversion Principle” (DIP).

 

(FYI: DIP and IoC's primary purpose is to decouple implementations of classes. With that come many benefits too long to go into in this post. But I highly recommend following the links provided in this article to learn more.)

 

I have heard this before and I agree that IoC is definitely not something new. But there are some differences. “Dependency Inversion Principle” is an Object Oriented Design principle where as “Inversion of Control” is a Design Pattern. Principles are meant to be followed but provide only the basic guideline to follow where as Patterns are concrete solutions to common problems so there alone separates their purpose/intent. Personally I think that Ioc is at the core of DIP, but they both compliment each other but in different aspects. (Think chicken before the egg?) The only way you can have a good, successful dependency inversion of a class is by using one of the IoC patterns (I, II, or III) or also as my friend suggested to me the alternative design pattern “plugin”.

 

Then as my friend asked, what is the hype about IoC containers and when do we use an IoC contatiner over creating our own Plugin? (Paraphrasing here)

 

First what is a plugin? To summarize, it links classes during configuration rather than compilation. The plugin depends heavily on factories and some conditional logic to decide which implementation to return to the requesting client. The plugin can be used in many contexts but the author originally wrote its primary purpose for unit testing or running an application in multiple environments. Factories can be evil for reasons like that they usually implement the singleton, or another problem is that now you may have avoided tightly coupling two object implementations by using DIP but the requesting client is still tightly coupled to a factory class to get it’s loosely coupled implementation.

 

What about IoC. Using an IoC container assists us in DIP without recreating the wheel. Though each container use different ways (see below) of binding implementations dynamically during runtime…none of them use a factory to that. We can also now choose our preferred method of IoC using open freely available frameworks. I wont go to company A and have to learn company A’s proprietary IoC framework and then do the same again for company B, company C, and so on. – Standardization is good.

 

*Very Quick Reference to how IoC is implemented in frameworks. I use the dependency injection terms (setter, constructor, interface) over the original IoC terms (I, II, III). Martin Fowler provides us with an easier way of understanding this pattern.