Dependency Inversion Principal

Dependency Inversion Principle (DIP) is one of the five software design principles. What programming languages you know, you should know these five principles written below :

• Open Close Principle(OCP)
• Dependency Inversion Principle (DIP)
• Interface Segregation Principle (ISP)
• Single Responsibility Principle (SRP)
• Liskov’s Substitution Principle (LSP)

In this article, i will explain Dependency Inversion Principle.

Purpose / Reason
This principle’s purpose is not to provide strong correlation between high level classes and low level classes. The reason of using DIP is that changing in low level class shouldn’t affect high level class. When you need some change in low level classes, you shouldn’t need to change code in high level classes. For clarifying , let’s see a bad example and good example respectively, thus, you can understand better.

Key Principles
High level classes should not depend on low level classes. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

Implementation
For this case, you build log manager 6 months ago to track user’s action. For this aim, you decided to insert log into database. But right now, your manager wanted that log must be inserted into file.

Bad Example :
Here is the code that you wrote 6 months ago to track user actions.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public class LogDB {     public void AddLog()     {         // Add log into database     } }   public class LogManager {     LogDB log = new LogDB();       public LogManager(LogDB log)     {         this.log = log;     }       public void Log()     {         this.log.AddLog();     } }

Here is the new low level class you write to insert log into file. It needs to be implemented current structure.

1 2 3 4 5 6 7

public class LogFile {     public void AddLog()     {         // add log into file     } }

When you try to implement LogFile into current class structure. You will have to change LogManager classes. Using this bad solution, you have these problems written below :

• The code statement where you used to invoke LogManager.Log() method.
• You have to redone your unit testing.

It’s obvious, you are able to implementing new requirements into your current code. However, it won’t be a good solution. Because, you will need to modify all related classes to Log Business Logic.

Let’s see how you can build better using Dependency Inversion Principle

Good Example :
According to this principle, the way of building class structure is to start from high level classes to  low level classes. And put abstract class or interface between high level classes and low level classes.

High Level Classes ==> Abstraction ==> Low Level Classes

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

//ILog is a abstraction. public interface ILog {     void AddLog(); } // LogManager is a high level class public class LogManager {     ILog log;     public LogManager(ILog log)     {         this.log = log;     }       public void Insert()     {         this.log.AddLog();     } } // LogDB is a low level class public class LogDB : ILog {     public void AddLog()     {         // insert log into database     } } // LogFile is a low level class public class LogFile : ILog {     public void AddLog()     {         //insert log into file     } }

Summary 
If you build your class structure in respect of DIP, you can implement new low level class such as LogFile without changing any code in your high level class ( LogManager ). Also you minimize the risk to affect old functionality. Beside that, you don’t need to rewrite your unit testing for LogManager class.

For this good example, as you see, LogManager (High Level Class) doesn’t know anything about low level classes. It knows only interface of log classes (ILog).

When you use DIP, you have more flexible. But this principle can not be applied for every class. If you have a class functionalities these are more likely to remain same, unchanged in the future, you don’t have to apply this principle.