Dependency Inversion Principle, Inversion of Control and Dependency Injection

To understand Dependency injection (DI) we need understand two things. First Dependency Inversion Principle (DIP), second Inversion of Controls (IoC). We’ll start with DIP.

Dependency Inversion Principle

By conforming with the Dependency Inversion Principle guideline it allows use to write loosely coupled classes. The definition of DIP states:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend upon details. Details should depend upon abstractions.

The following is an example of a service which writes errors to a message log. The example consists of two classes, one writes messages to the error log, the other watches for errors being thrown by the system.

class WriteToErrorLog
{
	public void WriteEntry(string errorMessage)
	{
		// Write to error log here
	}
}

class SystemErrorWatcher
{
	// Handle for WriteToErrorLog to write error logs
	WriteToErrorLog writeToErrorLog = null;
	// This method will be called when the system encounters a problem
	public void Notify(string message)
	{
		if (writeToErrorLog == null)
		{
			writeToErrorLog = new WriteToErrorLog();
		}
		writeToErrorLog.WriteEntry(message);
	}
}

While this code is perfectly legit and deals with the job in hand, it violates DIP. The SystemErrorWatcher depends on the WriteToErrorLog class, which is concrete rather than an abstract class.

This wouldn’t necessarily be an issue if we stopped there. However we may want to introduce some extra functionality, such sending an email if a specific error occurs. We could create a SendEmail class who’s job is to send an emails. The handle could then be created in SystemErrorWatcher. But at any point in time we will only be using the WriteToErrorLog or SendEmail class.

DIP states we need to decouple a system so that higher level models such as the SystemErrorWatcher will depend on simple abstraction. This abstraction will be mapped to a concrete class which make things happen.

Inversion of Control

The IoC principle allows us to develop higher level modules which depend on abstractions rather than concrete classes.

So using IoC we amend the above example to decouple the SystemErrorWatcher class from the WriteToErrorLog class. To do this we need to create an interface which provides the abstraction to act upon notifications received from the SystemErrorWatcher.

public interface INofificationAction
{
	public void ActOnNotification(string message);
}

Next change the SystemErrorWatcher to use the above interface

class SystemErrorWatcher
{
           // Handle for WriteToErrorLog to write error logs
           INofificationAction doSomething = null;
           // This method will be called when the system encounters a problem
           public void Notify(string message)
           {
                  if (doSomething == null)
                  {
                         // We need to map the abstraction to the concrete class here
                  }
                   doSomething.ActOnNotification(message);
           }
}

To complete this change we now need to update the WriteToErrorLog class so it implements the new INofificationAction interface.

class WriteToErrorLog : INofificationAction
{
	public void ActOnNotification(string errorMessage)
	{
		// Write to error log here
	}
}

In addition to emails we may want to send an SMS. Now we’ve decoupled we can create two concrete classes, one for email the other SMS which both implement the INofificationAction interface.

class EmailSender : INofificationAction
{
	public void ActOnNotification(string message)
	{
		// Send email from here
	}
}
class SMSSender : INofificationAction
{
	public void ActOnNotification(string message)
	{
		// Send SMS from here
	}
}

By doing this the high level models are now dependent on lower level abstractions rather than concrete classes. This is exactly what dependency inversion principle states.

However we still have one piece of the puzzle missing, we never create the concrete type to make something happen. We could modify the class to look like this.

class SystemErrorWatcher
{
      // Handle for WriteToErrorLog to write error logs
      INofificationAction doSomething = null;
      // This method will be called when the system encounters a problem
      public void Notify(string message)
      {
            if (doSomething == null)
            {
                   // We need to map the abstraction to the concrete class here
                   writeToErrorLog = new WriteToErrorLog();
            }
            doSomething.ActOnNotification(message);
      }
}

But by doing this we’ve introduced another dependency. This is where Dependency injection comes in.

Dependency Injection

Dependency Injection is mainly used for injecting concrete implementations into a class which is using abstractions. This will allow us to reduce the coupling between classes and move the binding between interface and concrete class out of the dependent class.

DI come in three forms, Constructor Injection, Method Injection and Property Injection.

Constructor Injection

This allows use to pass in the concrete implementation to the dependent classes constructor. We then assign this the interface created with in this classes. By doing this we can pass in any concrete class which is implements the interface we need to bind to. In our example this will allow us to pass in WriteToErrorLog, EmailSender and SMSSender concrete classes as these all implement the INofificationAction interface.

class SystemErrorWatcher
{
      // Handle for WriteToErrorLog to write error logs
      INofificationAction doSomething = null;
      public SystemErrorWatcher(INofificationAction concreteImplementation)
      {
            doSomething = concreteImplementation
      }
      // This method will be called when the system encounters a problem
      public void Notify(string message)
      {
            doSomething.ActOnNotification(message);
      }
}

The calling class can now do

WriteToErrorLog writeToErrorLog = new WriteToErrorLog();
SystemErrorWatcher systemErrorWatcher = new SystemErrorWatcher(writeToErrorLog); 
systemErrorWatcher.Notify("Something has broken");

Now if we want to send an email instead of writing to the error log.

EmailSender emailSender = new EmailSender();
SystemErrorWatcher systemErrorWatcher = new SystemErrorWatcher(emailSender); 
systemErrorWatcher.Notify("Something has broken");

Method Injection

This is similar to Constructor Injection but this time we pass the concrete class to the method rather than constructor. We use this if we don’t want the dependent class to use the same concrete class for it’s entire lifetime.

class SystemErrorWatcher
{
      // Handle for WriteToErrorLog to write error logs
      INofificationAction doSomething = null;

      // This method will be called when the system encounters a problem
      public void Notify(INofificationAction concreteImplementation, string message)
      {
            this.doSomething = concreteImplementation
            doSomething.ActOnNotification(message);
      }
}

The calling class now becomes

WriteToErrorLog writeToErrorLog = new WriteToErrorLog();
SystemErrorWatcher systemErrorWatcher = new SystemErrorWatcher(); 
systemErrorWatcher.Notify(writeToErrorLog, "Something has broken");

Property Injection

If the responsibility of selection of the concrete class and invocation methods are in separate places, we need to use property injection.

Here was pass the concrete class via a setter that’s exposed by the dependent class. To do this the SystemErrorWatcher class will look like this.

class SystemErrorWatcher
{
      // Handle for WriteToErrorLog to write error logs
      INofificationAction doSomething = null;

      public INofificationAction DoSomething
      {
            get
            {
                  return action
            }
            set
            {
                  action = value
            }
      }

      // This method will be called when the system encounters a problem
      public void Notify(string message)
      {
            doSomething.ActOnNotification(message);
      }
}

The calling class

SystemErrorWatcher systemErrorWatcher = new SystemErrorWatcher();
systemErrorWatcher.DoSomething = new WriteToErrorLog();
systemErrorWatcher.Notify("Something has broken");

If we want to send an SMS.

SystemErrorWatcher systemErrorWatcher = new SystemErrorWatcher();
systemErrorWatcher.DoSomething = new SMSSender();
systemErrorWatcher.Notify("Something has broken");