Inversion of Control - IoC

Inversion of Control (IoC) is an approach in software development that favors removing sealed dependencies between classes in order to make code more simple and flexible. We push control of dependency creation outside of the class, while making this dependency explicit.

Usage of Inversion of Control generally allows to create applications that are more flexible, unit-testable, simple and maintainable in the long run.

Consider the sample:

public class Car
{
  Engine _engine;

  public Car()
  {  
    _engine = new Engine();
  }
}

Here we have extremely strong dependency between Car and Engine. We actually, can't install any other engine inside, since Car controls instantiation of that Engine.

Let's open up the design a little bit:

public class Car
{
  IEngine _engine;

  public Car(IEngine engine)
  {
    _engine = engine;
  }
}

Now we have moved the control over the Engine creation outside of the Car and into the code that creates it. This is called Inversion of Control or IoC for short.

Often control over the dependency creation is delegated to specialized application blocks called Inversion of Control Containers. IoC containers are really good in determining dependencies that are needed to create a specific class and injecting them automatically. This process is often called Dependency Injection.

Consider the following example for Autofac IoC Container for .NET (there are many others as well):

// configuration that happens only once.
var builder = new ContainerBuilder();
builder.Register<Car>();
builder.Register<Engine>().As<IEngine>();

var container = builder.Build();

// somewhere in the code
var car = container.Resolve<Car>();

Inversion of Control and Dependency Injection can do much more than that. Check the links at the end of this article for more details.

Here are just some hints on what could be done without changing Car and Engine classes:

• automatically check IEngine for failures when it is plugged into the Car;
• write a log message every time we start the IEngine;
• plug-in a spare IEngine whenever the original engine fails;
• add a security check to prevent unauthorized driver from starting the Car.

Engine class from the example above could be called a component implementing IEngine service contract. Development approach that relies on separating code into composable and reusable components is called Component-Driven Development. It brings additional benefits in conjunction with IoC. One of these benefits is about injecting cross-cutting concerns that allows to avoid complex and repeatable code in a lot of scenarios.

Related links:

• 10 Steps To Become Better .NET Developer
• Component-driven development and IoC Containers
• Autofac Inversion of Control Container for .NET
• Structuring .NET Applications with Autofac IoC
• What is Inversion of Control on StackOverflow
• Inversion of Control on Wikipedia.

List of popular IoC Containers for .NET:

(in the order of preference)

• Autofac
• Castle Windsor
• Unity
• StructureMap
• NInject
• Spring.NET

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Comments

[Giorgio Sironi]

Checking the engine when plugged in is not something I'm used to, since doing work in the constructor makes Car hard to test. Thanks to inversion of control we can set up a mock IEngine instance to pass to the constructor of Car to test it in isolation; but if we call something on the engine in the constructor of Car we'll need to mock those methods of IEngine every time we write a test. For the other parts, nice article. :)

[Rinat Abdullin]

Giorgio,

putting any complex logic into the constructor is not a good idea, indeed (and that's the approach I always try to enforce).

Yet, the point was to achieve that without changing Car and Engine classes (i.e.: by simply executing engine test routine from within engine creation event in the IoC Container)

[John]

It is good to see someone write up a really simple IoC example building on Autofac. Thanks.