IOC container & accessing Implementation from the container

Question

Background

As mentioned in this article,

Inversion of Control can be achieved through various mechanisms such as: Strategy design pattern, Service Locator pattern(SLP), Factory pattern, and Dependency Injection (DI).

Am missing clarity in above statement, because below is my understading.

1) Creation of container

Creating a dependency container or IOC container does not require any of these design patterns(mentioned above). We need these design patterns to get access to an implementation from that container(which is already created). Here is the C code where init_handlers() create a container(imagehandlers in config.c) of implementations that are configured in config.txt

2) Access impl from the container

To get access to an implementation from the container, for example,

One can rely on injection mechanism that is implementated using DI pattern.

or

Rely on service location mechanism that is implemented using Service locator pattern. Here is the C code where displayMenu() locates the service from imagehandlers container, based on given input(scanf("%s",filename);)

---

So, Dependency Injection or Service locator pattern has nothing to do with creation of IOC container but to get access to an implementation from that container.

For example, In Spring,

ApplicationContext appContext = new ClassPathXmlApplicationContext("Springbeans.xml")

create the IOC container with singleton instances of all beans configured in Springbeans.xml assuming the beans are not prototype-scoped and

MessageBean mBean = (MessageBean)appContext.getBean("messagebean"); 

locates the messageBean service using service locator pattern from appContext container.

1) For this line of code ApplicationContext appContext = new ClassPathXmlApplicationContext("Springbeans.xml") that creates a dependency container, Is it right to say that, creation of container has nothing to do with design pattern(like DI or SLP)?

2) Why appContext is not called a dependency container? Instead, why appContext is called IOC container?

Answer 1

Unity, for example, is referred to as a dependency injection container

https://msdn.microsoft.com/en-us/library/ff647202.aspx

Microsoft get it right again, this is why you should never use java.

I think it would be fair to say that a DI Container is, at least in part, the implementation of the patterns you list.

Say I have a class set up to have a service injected

class myClass
{
    myClass(IService s)
}

I can, and probably would in most cases, simply instantiate it 'manually' in code

main(string[] args)
{
    var m = new myClass(service);
}

However. If im working in a framework of some kind, often I wont be coding the low level structure of the app. Just Views, ViewModels, Controllers, Behaviours or some other object types which the framework itself will instantiate as needed.

In this case I don't have the opportunity to code that instanciation. Instead I need to provide the framework with some factory methods, so that when it creates my classes it can inject whatever is required.

Rather than hand code a factory for each class I can use reflection to create a generic factory that can create any class. This is the IoC or DI Container object.

Answer 2

A IoC/DI Container is a framework for managing dependencies of an application.Since it is a framework it should define a way of creating, and loading/injecting particular dependencies when and where required. So the part

1) Creation of container

Creating a dependency container or IOC container does not require any of these design patterns(mentioned above)...

is not right per se, since you are refering to an object creation while a framework describes a way of achieving a certain goal, i.e the steps, design patterns and mechanisms.

The use of dependency injection mechanism, in fact makes the term dependency injection container more appropriate, so i would agree with your second thought. Dependency injection is a way-mechanism for achieving IoC and dependency inversion.

For further reading and better understanding i suggest you take a look at the links below:

1. Difference between “Inversion of Control”, “Dependency inversion” and “Decoupling”
2. What is IoC Container or DI Container
3. Understanding Inversion of Control, Dependency Injection and Service Locator

Answer 3

1. For this line of code ApplicationContext appContext = new ClassPathXmlApplicationContext("Springbeans.xml") that creates a dependency container, Is it right to say that, creation of container has nothing to do with design pattern(like DI or SLP)?

This thing is a Service Locator. But the anti pattern with service locators is to spread them around. Keep this only in your composition root (typically main) and it's fine.

2. Why appContext is not called a dependency container? Instead, why appContext is called IOC container?

IOC depends on polymorphism. That requires not knowing exactly what you're talking to. That's being accomplished here by forcing you to separate construction code from behavior code in the most extreme way possible. By making construction happen in a different language (typically xml). That separation keeps the using code from knowing exactly what it's talking to.

I could dump a bunch of things I depend on in a collection and call it a dependency container. They likely wanted a name that indicated they'd done more work than that.