SOLID - DIP - Everything You Should Know About the Dependency Inversion Principle

It's time to decipher the last, but definitely not the least important letter of SOLID, i.e. D for Dependency Inversion Principle.

This principle says that:
-High-level modules should not depend on low-level modules. Both should depend on abstraction.
-Abstractions should not depend on details. It is the details that should depend on the abstraction.

The systems we write should address abstractions (through the use of interfaces or abstract classes), not concrete elements. By following the principle of dependency inversion, we minimize dependencies (loose coupling) in the application. This will make our applications more flexible and make changes easier in the future.

SOLID - DIP - Everything You Should Know About the Dependency Inversion Principle (DIP)

Code that does not follow the dependency inversion rule:

public class Employee
{
    public string Name { get; set; }
}

public class EmployeeRepository
{
    public void Add(Employee employee)
    {
        //Add employee to database
    }
}

public class EmployeeService
{
    private EmployeeRepository _employeeRepository = new EmployeeRepository();

    public void Add(Employee employee)
    {
        _employeeRepository.Add(employee);
    }
} 

Let's first define the basics, i.e. what are high-level modules and what are low-level modules, without this you will not understand the principle of dependency inversion. In the above code, the high-level module is the EmployeeService class and the low-level module is the EmployeeRepository class. The high-level module in this example depends on the low-level module because it uses a specific implementation, the EmployeeRepository class, and this violates the DIP principle. To make this code compatible with DIP, we need to reverse these dependencies (as the name says). What's the best way to do this? An implementation where the dependencies are reversed may look, for example, as in the example below.

Code that follows the dependency inversion principle:

public class Employee
{
    public string Name { get; set; }
}

public interface IEmployeeRepository
{
    void Add(Employee employee);
}

public class EmployeeRepository : IEmployeeRepository
{
    public void Add(Employee employee)
    {
        //Add employee to database
    }
}

public class EmployeeService
{
    private IEmployeeRepository _employeeRepository;

    public EmployeeService(IEmployeeRepository employeeRepository)
    {
        _employeeRepository = employeeRepository;
    }

    public void Add(Employee employee)
    {
        _employeeRepository.Add(employee);
    }
} 

In the above example, our EmployeeService no longer depends on a specific EmployeeRepository implementation, but only on an abstraction. In this case, from the IEmployeeRepository interface. Changes to a low-level module do not affect the high-level module. In this way, it was possible to reverse the dependencies. Now, according to the Dependency Inversion Principle, the high-level module no longer depends on the low-level module, but depends on the abstraction. A high-level module is not interested in changes that will be made to a low-level module. The only important thing is that it implements the above interface.

Introduction to Dependency Injection (DI)

public class Program
{
    static void Main()
    {
        var employeeService = new EmployeeService(new EmployeeRepository());
    }
} 

However, a better solution is to also create an interface for IEmployeeService and instantiate new classes by using the Dependency Injection container. By using the Dependecy Injection container, after proper configuration, you can operate on interfaces in your application and you will be less likely to create objects via "new". I will try to write about what Dependency Injection is and how to implement Dependency Injection in one of my future blog articles.

SUMMARY