17 July 2013

What is a Inversion of Control Containers and the Dependency Injection pattern ? (including Useful link: article Martin Fowler )

Just in case.
This is about IT term. It is NOT about process of getting addicted from dugs.
Dependency injection is giving an object its instance variables (via constructor,method and etc) and remove dependencies from your code.
That would "inject" the "dependency" into the class.

This article has almost 10 years and is made by man is a agile knight and fighting for fame of agile development.

It is about  "Inversion of Control"   paradigm and his one of implementation the "Dependency Injection" pattern.It is worth to learn,when you start using spring framework and any containers that based on  "Inversion of Control"   paradigm.

If you have a clue what  Inversion of Control and   Dependency Injection are ,then  read these 2 micro article first.:

It will you explain what    Inversion of Control  is.

It will you explain what  Dependency Injection is.

After that , You should be read to read  Martin Fowler - Inversion of Control Containers and the Dependency Injection pattern. (You need above articles as Martin Fowler article is very academic ,which means write about simple things as complicated ,  confusing and mysterious  as is possible . )
(I suggest drink a strong coffee before you will read it.)


 A few quotes  from article (and 2 links):

" The Inversion of Control (IoC) and Dependency Injection (DI) patterns are all about removing dependencies from your code. " urini

" Dependency injection means giving an object its instance variables. Really. That's it. " James Shore

"When these containers talk about how they are so useful because they implement "Inversion of Control" I end up very puzzled. Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels. "  Martin Fowler

" I've often heard the complaint that these kinds of service locators are a bad thing because they aren't testable because you can't substitute implementations for them. Certainly you can design them badly to get into this kind of trouble, but you don't have to. In this case the service locator instance is just a simple data holder. I can easily create the locator with test implementations of my services. " Martin Fowler

" A common reason people give for preferring dependency injection is that it makes testing easier. The point here is that to do testing, you need to easily replace real service implementations with stubs or mocks. However there is really no difference here between dependency injection and service locator: both are very amenable to stubbing. I suspect this observation comes from projects where people don't make the effort to ensure that their service locator can be easily substituted. This is where continual testing helps, if you can't easily stub services for testing, then this implies a serious problem with your design. " Martin Fowler

" If you use Dependency Injection there are a number of styles to choose between. I would suggest you follow constructor injection unless you run into one of the specific problems with that approach, in which case switch to setter injection. If you are choosing to build or obtain a container, look for one that supports both constructor and setter injection. " Martin Fowler

" The choice between Service Locator and Dependency Injection is less important than the principle of separating service configuration from the use of services within an application. " Martin Fowler
Interesting stuff.