In this article, we will try to understand the concept of dependency injection and inversion control. The basic idea behind dependency injection is that:
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend upon details. Details should depend upon abstractions.
These points here suggest that whenever we have a piece of code, where one class needs to use another class, for some functionality, the main class should not directly refer to the required class. It should always depend on the abstraction rather than its concrete implementation. Let’s see with an example what we mean over here:
public class TestClass
{
ILogger logger;
public void GetData()
{
try
{
//Get some data
}
catch (Exception ex)
{
logger.SaveException();
}
}
}
public class Logger
{
public void SaveException()
{
//Log the exception to textfile
}
}
Consider the piece of code above. Here, we have a test class, which executes the GetData function. In case any exception occurs, the catch block logs the error in a text file, using the SaveException method in the Logger class. So here we can see that the GetData method is directly dependent on the Logger class to save the exception to text file.
The above implementation seems to be fine until we have a requirement that we would like to save the exception to database, instead of the text file. In such a case, we will add another method and call that method say, SaveExceptionToDatabase. Further, if we need to save the exception in any other form, again we need to change the code in this class and then call that new method. So this will be a problem as we have to change the code whenever there is a new implementation and moreover, we may break the existing GetData method by these changes.
This is where the abstractions are useful. We implement the abstractions using the interfaces and main classes use these abstractions, which is nothing but the concept of Inversion of control, which is used to make a high level module dependent on the abstractions rather then the concrete implementations.
So in order to do this, we will change our code and add an interface named ILogger with a single method named SaveException. We also add two classes named DBLogger and TextLogger. Both these classes will implement the ILogger interface. So the code will change to:
public interface ILogger
{
void SaveException();
}
public class DBLogger : ILogger
{
public void SaveException()
{
//Save Exception to database
}
}
public class TextLogger : ILogger
{
public void SaveException()
{
//Save Exception to text file
}
}
Next, we need to change the GetData function to use the dependency through abstraction instead of the concrete implementation. For this, we change the code to remove the Logger class instance and use the ILogger instance. So the code changes to:
public class TestClass
{
ILogger logger;
public void GetData()
{
try
{
//Get some data
}
catch (Exception ex)
{
logger.SaveException();
}
}
}
Now, the point is, we have changed the main class to use the dependency through interface, but how does the GetData receive the dependency i.e. the concrete implementation for ILogger which could be either DBLogger or TextLogger. This is where we have the concept of dependency injection. We will inject the dependency into the class. For this purpose, we can use the following three techniques.
- Constructor injectionInject the dependency through the constructor of the class.
- Method injectionInject the dependency through the method of the class, which requires dependency.
- Property InjectionInject the dependency through a property in the main class.
We will discuss these techniques in our next articles. For complex scenarios where we may have nested or multiple depdendencies, we have the concept of IoC containers to map the dependencies. Happy coding...!!!
No comments:
Post a Comment