Question

read many posts about the difference between the 3 idioms. But got more confused, then I ran into this article:
http://martinfowler.com/articles/injection.html

just want to see if I got this right. please correct me if I’m wrong.
Please notify me of correction and additions:

IoC- is the concept of decoupling an application from the implementation of a service it uses. The application contain a ref to Iservice and is not incharge of instanciating the concrete service.

There are at least two way to achive so:

1. DI – The concrete service is injected as a ctor param/throw a setter/throw interface injection (what does the latter mean?)

2. ServiceLocator – is a component that knows all the concrete services the application may need. The application explicitly asks for the concrete service from the Locator.

*IoC container is actualy a controls’ factory (“provider”).

I got a bit confused by the “when to prefer (1) or (2)” part in the article. could someone please tell from his own experience in a layman words ?

“Service Locator has a slight edge due to its more straightforward behavior. However if you are building classes to be used in multiple applications then Dependency Injection is a better choice.”–> How is locator more straightforward ? because it uses method invocation explicitly ? What is it better to use DI when there are multiple applications?

Answer 1

IoC is the concept of decoupling an application from the implementation of a service it uses.

It is true that IoC goes hand in hand with decoupling interfaces from implementations, but I see it as a more general principle. This SO answer gives a very good explanation of the concept.

There are at least two way to achive so:
1) DI
2) ServiceLocator

I wouldn’t say that the Service Locator pattern is an example of Inversion of Control. Quite the opposite – when you are using the Service Locator, you are acquiring the required dependencies in active way, nobody else does it for you (contrary to the DI, where the container handles the dependencies for you, you just have to give it a possibility of doing so – a setter, a constructor parameter or by implementing method of injection interface).

How is locator more straightforward ? because it uses method invocation explicitly?

I think that Martin Fowler is referring to the general idea of IoC that may make the code harder to understand if you’ve never seen the IoC/DI concept used before. On the other hand, the code using Service Locator to acquire some dependencies may be easier to grasp on first encounter.

What is it better to use DI when there are multiple applications?

When you are creating a component that is supposed to be reusable, the advantage of DI is that it doesn’t make your component dependent on anything else than the original dependency (in MF’s example, the MovieLister depends only on the MovieFinder interface when using DI).
Also, it is quite easy for others to use your component – the just have to pass the dependencies using the means of DI you provided.

When using the Service Locator, you also add dependency on the interface of the Service Locator itself. With segregated interface for the Locator, that may not be a problem. But it may also be harder for users of your component to satisfy the dependencies of your component, as MF writes:

The difference comes if the lister is a component that I’m providing to an application that other people are writing. In this case I don’t know much about the APIs of the service locators that my customers are going to use. Each customer might have their own incompatible service locators.