Solid principles: 5. Dependency inversion principle

Today about the last and very important principle of SOLID, Dependency inversion.

The definition of the Dependency inversion principle from wikipedia is:

High-level modules should not depend on low-level modules — the relationships between them should result from abstraction.

In other words, in classes and methods, we should not use any names of specific classes, that should be names only interfaces and abstract classes.

Also, classes should not inherit from specific classes, only after abstract classes and interfaces.

What would happen if high-level modules depended on low-level modules?

If, for example, we changed something in the class after which another class inherits, then these changes could throw something in the class inheriting from it, so using classes that depend on low-level modules would be very difficult because when we change something in this class we will probably have to change something in the class after which she inherits.

However, if we reverse this dependence, reusing such classes will be very easy.

Let’s see how it looks in practice:

public void Pay(PayPal paypal)
{
//.....
}

This is an example of a method that implements paying PayPal, you can not write something like this, the above example is now dependent on the PayPal class

It should look like this:

public void Pay(IPayPal paypal)
{
//.....
}

Now our example depends on abstraction, i.e. from the interface of IPayPal, now we do not care what is happening in the low-level modules, i.e. in the previous example in the PayPal class. The Pay method simply implements the IPayPal interface.

It gives more or less that we can change the methods of the IPayPal interface.

This approach also makes it very easy to get other classes to some libraries and use them in other projects, if we did not use this approach, we would have to drag all the classes we used or the mass of references.

Let’s do some other example:

class Program
{
    static void Main(string[] args)
    {
        var bank= new Bank();
    }
}
 
public class Bank
{
    ...
    public Bank()
    {
        _pay=new Pay();
    }
 
    ...
}
public class Pay
{
    public void PayCard()
    {
        //pay with the card
    }
 
    public void PayPal()
    {
        //pay via PayPal
    }
}

In this example, we have no influence on what payments we will use, the high-level module is the bank, and low-level payments, in the constructor is saved what payments we will use.

How should this example look good? More or less:

class Program
{
    static void Main(string[] args)
    {
        var pay= new Pay();
 
        var bank= new Bank(pay);
    }
}
 
public class Bank
{
    ...
    public Bank(IPay pay)
    {
        _pay=pay
    }
 
    ...
}
 
interface IPay
{
    void PayCard();
    void PayPal();
}
 
public class Pay,IPay
{
    public void PayCard()
    {
        //pay with the card
    }
 
    public void PayPal()
    {
        //pay via PayPal
    }
}

Now we can choose the payment ourselves without having to go deep into the low-level modules.

Summary

That’s all about Dependency inversion principle.

This principle is related to two very important patterns that tell you exactly what ways to avoid multi-level dependencies and how to facilitate the writing of multi-level dependencies, from which are the so-called containers these patterns include dependency injection and inversion of control. Both are described here.

This content also you can find on my blog https://steemit.com/solid/@slawas/solid-principles-5-dependency-inversion-principle

And on my blog devman: http://devman.pl/programtech/solid-principles-5-dependency-inversion-principle/

As a standard, I remind you about the newsletter, which I send notifications about new entries and additional information about the IT world in general.

And NECESSERILY join the DevmanCommunity community on fb, part of the community is in one place

– site on fb: Devman.pl-Sławomir Kowalski

– group on fb: DevmanCommunity

You have to understand all the solid principles from the top to the top, they are very important at all in programming, thanks to them you will be able to maintain large projects and make them in such a way that they are easy to modify, expand, understand, etc.

Ask, comment underneath at the end of the post, share it, rate it, whatever you want.