So far we have gone through Single Responsibility Principle, Open Closed Principle , Liskov Substitution Principle, Interface Segregation Principle which cover four SOLID principles. In this post, we will go through D ie Dependency Inversion Principle.

DIP says that the most stable systems are those in which source code dependencies refer to abstractions and not to concretions.

Dependency inversion principle cannot be followed as rule because in reality we have to depend on concrete implementations like operating systems, platforms, String in Java, etc. The dependencies like these which are stable and very unlikely to change are excluded from this principle. 

The dependencies that are volatile, that are still developing, that can change, we should be depending on their interfaces and not on concrete implementations. 

Stable Abstractions

Stable architectures are those that avoid depending on volatile concretions and that favor the use of stable abstract interfaces. They follow following rules – 

1. Don’t refer to volatile concrete classes
2. Don’t derive from volatile concrete classes
3. Don’t override concrete functions – concrete functions have dependencies, when you override them, you inherit these dependencies. So ideally we should make functions abstract and create multiple functions.
4. Never mention the name of anything concrete and volatile

Thanks for stopping by! I hope this gives a good preview into DIP. Eager to hear your thoughts and chat, please leave comments below and we can discuss.