We all know that the Java language is OOP. In the Java development process, abstraction generally refers to excuses and classes. The Dependency Inversion Principle is also known as the Dependency Inversion Principle.
What is the Dependency Inversion Principle in object-oriented programming?
Defined as follows:
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
which is:
A. High-level modules should not depend on low-level modules, but should depend on abstractions (interfaces).
B. Abstraction (interface) should not depend on concreteness, but concreteness depends on abstraction.
Let’s understand it in detail. For example, Xiaoming, the code farmer (why is Xiaoming lying on the gun (╥╯^╰╥)) wears a sweater, which may be round neck or heart neck, and may be blue , may also be red.
interface Coder {
void wearSweater(Sweater sweater);
}
class XiaoMing implements Coder{
@Override
public void wearSweater(Sweater sweater) {
}
}
interface Sweater {
}
class TneckSweater implements Sweater {
}
Then we look at how the client code is written:
Coder xiaoming = new XiaoMing();
Sweater tneckSweater = new TneckSweater();
xiaoming.wearSweater(tneckSweater);We assume that there are 6 Coders in the project team, including Xiaoming, Dalong, and Lao Zhang. Some of them like to watch Korean dramas, some like to watch anime, some like Lin Chiling, and some like to listen to rock. But they probably all wear sweaters when it's cold, some in Metersbonwe, some in pure. Then when we write the code, we know that the interface has the method of wearing sweaters. For different sweaters, we create different instances. As long as the number is no problem, we can wear them. Isn't it easy to expand? φ(゜▽゜*)♪
We see that programming is aimed at a more abstract interface, and concrete classes depend on abstract interfaces. That is, for specific classes, do not depend on each other, but program against the interface.
In this picture, we can also intuitively see the application of the dependency inversion principle.
The Dependency Inversion Principle is based on the fact that abstract things are much more stable than details are variable. Architectures built on abstraction are much more stable than architectures built on details.
Advantages of using DIP:
- reduce coupling between classes
- Improve system stability
- Improve system maintainability and scalability
Of course, using this principle results in more classes and interfaces to maintain, but more flexibility. The Dependency Inversion Principle should not be used blindly in modules. For example, some functional classes do not need to use this principle.
Best Practices:
- Try to have an excuse or abstract class for each class
- The type of the variable should be declared as an excuse or an abstract class as much as possible
- Try not to overwrite the method of the parent class
- Use in conjunction with the Liskov Substitution Principle
refer to:
https://en.wikipedia.org/wiki/Dependency_inversion_principle
http://blog.csdn.net/moxiaoya1314/article/details/51899048
https://springframework.guru/principles-of-object-oriented-design/dependency-inversion-principle
《The Dependency Inversion Principle》