This principle says the decoupling of software modules. This way, instead of high-level modules depending on low-level modules, both have to depend on abstractions
The classical example of this principle of bean configuration in the Spring framework.
Another very good example of this principle:
When you go to a local store to buy something, and you decide to pay money for it by using your debit card. So, when you give your card to the shopkeeper for making the payment, the shopkeeper doesn’t bother to check what kind of card you have given.
Even if you have given a Visa card to a shopkeeper, he will not put out a Visa machine for swiping your card. The type of debit card or credit card that you have for paying does not even matter. They will simply swipe it. So, in this way, you can see that both you and the shopkeeper are dependent on the credit or debit card abstraction and you are not worried about the specific of the card. This is what a dependency inversion principle is.
Why is this principle required?
It allows a programmer to remove hardcoded dependencies from source code so that the application becomes loosely coupled and extendable.
An example to clarify this principle:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
package com.kkjavatutorials.model; public class Employee { private Address address; public Employee(Address address) { this.address = address; } public Address getAddress() { return address; } } |
In the above source code, the Employee class requires an Address object and it is responsible for initializing and using the Address object. If the Address class is changed in the future then we have to make changes in the Employee class as well. This makes the tight coupling between Employee and Address classes. We can resolve this problem using the dependency inversion design pattern. i.e. Address object will be implemented independently and will be provided to Employee when Employee is instantiated by using constructor-based or setter-based dependency inversion. Spring Framework is a very good example of the Dependency Inversion Principle
You May Also Like:
Adapter Pattern
Decorator Pattern
Facade Pattern
Proxy Pattern
Composite Pattern
Flyweight Pattern
Bridge Pattern
That’s all about the Dependency Inversion Principle (DIP)
If you have any feedback or suggestion please feel free to drop in below comment box.