Inversion of Control

Lately I’ve been giving a couple of presentations on the subject of automated testing of websites. According to myself and the feedback I’ve gotten one of the most important parts of the presentations has been the part about Inversion of Control.

I thought I’d write down that part of the presentation in an introduction to Inversion of Control, using Dependency Injection and Service Locator along with some examples in .NET (C# to be precise).

What is Inversion of Control?

According to Wikipedia “Inversion of Control, or IoC, is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming”.

The latter part of that quote is interesting. According to it Inversion of Control is a way to invert the flow of control in comparison to procedural programming.

What that means is that in procedural programming a chunk of code that uses, or consumes, another chunk of code is in control of the process.

It knows exactly what piece of code, what method in what class, it uses. And in doing so it is also quite likely that it knows about some implementation details in the code it uses.

An example

One example of such a scenario and of such a dependency is when a class, illustrated as X below, uses another class Y.

The consumer, X, needs the consumed class, Y, to accomplish something. That’s all good and natural, but does X really need to know that it uses Y?

Isn’t it enough that X knows that it uses something that has the behavior, the methods, properties etc, of Y without knowing who actually implements the behavior?

By extracting an abstract definition of the behavior used by X in Y, illustrated as I below, and letting the consumer X use an instance of that instead of Y it can continue to do what it does without having to know the specifics about Y.

In the illustration above Y implements I and X uses an instance of I. While it’s quite possible that X still uses Y what’s interesting is that X doesn’t know that. It just knows that it uses something that implements I.

That could be Y, but it could also be A, B or C given that they implement I. Of course this discussion is rather abstract at the moment, but we’ll get to how to implement this in a second using either Dependency Injection or Service Locator.

For now, let’s just assume that we can and that we can change what implementation of I X uses at runtime. What benefits can we get from that?

Benefits of Inversion of Control

Well, first of all X is not dependent on Y anymore and it’s therefore less likely that we’ll have to make changes to X when we make changes in Y as we’re less likely to write code in X that relies on implementation details in Y.

Furthermore X is now much more flexible as we can change which implementation of I it uses without changing anything in X.

Perhaps Y is a component for sending e-mails and we want X, who used to send e-mails, to start sending tweets instead using Z who also implements I. Since X no longer relies specifically on Y but on something that implements I we don’t have to modify anything in X.

Another benefit of inversion of control is also that we can isolate our code when creating unit tests.

Suppose, as before, that X used Y to send messages which Y did in the form of e-mails using an SMTP-server. When creating unit test, which should only test a single unit of code, we want to be able to test the logic in X without having to care about the component that sends messages, and we most definitely don’t want our tests to fail because Y doesn’t have access to an SMTP server.

Having used inversion of control X doesn’t rely on Y anymore but on an implementation of I that just happens to be Y.

That means that we, in the setup phase of our tests, can change it so that X uses a different implementation of I, such as a mock object which doesn’t send any messages at all, and which also allows us to check that X has used it in a correct way.

Applying Inversion of Control – A sample scenario

Enough with the X and the Y and I! Let’s look at a more concrete scenario.

We have a class named OrderService which is used for processing orders.

It has a method named AcceptOrder which receives an Order object, validates that it is valid according to the business rules (it may for instance check that the order’s shipping address is a valid address and that there are enough items in stock) and then, given that the order is valid, saves it to a database using another class named OrderDatabase.

The code for OrderService looks like this:

public class OrderService
{
    public void AcceptOrder(Order order)
    {
        //Domain logic such as validation

        new OrderDatabase().SaveOrder(order);
    }
}

Notice line seven above where AcceptOrder creates a new instance of the OrderDatabase class and then saves the order using it’s SaveOrder method. This might not be the most realistic scenario. In the real world SaveOrder could be static, making line seven in the example look like this:

OrderDatabase.SaveOrder(order);

Or there might a singleton implementation of OrderDatabase making line seven look like this:

OrderDatabase.Instance.SaveOrder(order);

Either way it doesn’t matter. What matters is that AcceptOrder relies on OrderDatabase which is something very concrete.

How OrderDatabase is implemented isn’t very important as long as we realize that relying on it is inflexible and bad for testability. For the sake of this example let’s assume it’s SaveOrder method looks like this:

public void SaveOrder(Order order)
{
    throw new ApplicationException("I need a database to work");
}

This will make it very hard to test the business logic in OrderService’s AcceptOrder method since it will call the SaveOrder method which in turn throws an exception.

To fix this we apply Inversion of Control by creating an abstract definition of the behavior in OrderDatabase that OrderService needs in the form of the interface IOrderSaver and making AcceptOrder use an instance of IOrderSaver instead of an instance of OrderDatabase.

OrderService no longer knows about the OrderDatabase class. It just uses an instance of the IOrderSaver interface of which OrderDatabase is one of possibly many implementation.

In fact we could easily change it so that OrderService instead uses a class that saves orders to XML files instead, without changing a single line of code in OrderService.

Or to a class that still saves to a database but that has been extended with logging.

Or to a composite that saves both to a database and to an XML file. Or to…

That’s all good, but how does OrderService get this instance of IOrderSaver you ask?

There would be little point in using the IOrderSaver interface if OrderService still had to know how to instantiate a concrete implementation of it, so we need a way for OrderService to get an instance of IOrderSaver at runtime without knowing about any concrete implementations.

There are a couple of ways to do that. Let’s begin by looking at Dependency Injection.

Dependency Injection

Using Dependency Injection we inject an instance of IOrderSaver into OrderService when we use it.

This could either be done using constructor injection, where we supply the instance to OrderService’s constructor, or property injection where we supply it to OrderService after it has been instantiated by setting a property on it.

In the diagram below I’ve tried to illustrate constructor injection.

Notice how OrderService has a constructor which requires an instance of IOrderSaver as a parameter. In code this could be implemented like this:

public class OrderService
{
    private IOrderSaver orderSaver;

    public OrderService(IOrderSaver orderSaver)
    {
        this.orderSaver = orderSaver;
    }

    public void AcceptOrder(Order order)
    {
        //Domain logic such as validation

        orderSaver.SaveOrder(order);
    }
}

As you can see in the example code above OrderService’s constructor requires an instance of IOrderSaver which it stores in a field. When invoked the AcceptOrder method uses this injected instance to save the order.

Should we want to be able to instantiate OrderService without supplying an IOrderSaver there is of course nothing stopping us from creating another constructor which sets the orderSaver field to a default implementation.

public OrderService()
{
    this.orderSaver = new OrderDatabase();
}

While this means that OrderService still knows about which implementation of IOrderSaver it uses when instantiated with this constructor we are still able to change what implementation it uses using the other constructor, for instance when we are creating unit tests.

I’m not saying this is a good idea, but it is possible and definitely better than not being able to change how OrderService saves orders at all.

Service Locator

While I think Dependency Injection is superior in just about any situation there is also another way to implement Inversion of Control, using a Service Locator.

In the diagram above OrderService doesn’t know about OrderDatabase but it does know about an instance of the concrete class ServiceLocator which in turn knows about OrderDatabase.

When AcceptOrder is invoked it will ask ServiceLocator for an instance of IOrderSaver which will supply one based on how we have configured it.

Using this approach OrderService could be implemented like this:

public class OrderService
{
    public void AcceptOrder(Order order)
    {
        //Domain logic such as validation

        OrderSaverFactory.GetOrderSaver().SaveOrder(order);
    }
}

A simple implementation of ServiceLocator would be to have it supply an instance of a default implementation of IOrderSaver unless we specifically tell it to supply another instance, like this:

public class ServiceLocator
{
    public static IOrderSaver OrderSaver { get; set; }

    public static IOrderSaver GetOrderSaver()
    {
        if (OrderSaver == null)
            OrderSaver = new OrderDatabase();

        return OrderSaver;
    }
}

I find the Service Locator approach to be much more messy than Dependency Injection and it makes unit tests harder to set up, but there might be a few situations where Dependency Injection may be impractical. Then it’s good to still be able to apply Inversion of Control by using Service Locator.