Design Patterns-six principles-Dependency inversion principles

Dependence Inversion Principle (DIP)
Definition
High level modules shocould depend upon low level modules. Both shocould depend upon quota actions. Quota actions shocould not depend upon details. Details shocould depend upon quota actions.
That is
1. High-level modules should not depend on low-level modules. Both of them should depend on abstract (abstract class or interface)
2. abstraction (abstract class or interface) should not depend on details (specific implementation class)
3. Details (specific implementation classes) should depend on abstraction
 
Abstract: an abstract class or interface. The two cannot be instantiated.
Details: a specific implementation class, an implementation interface, or an inherited class generated by an abstract class. The two can be directly instantiated using the new keyword.
 
In essence, the server Guard relies on the inversion principle to implement independent classes or modules through abstraction (abstract classes or interfaces) without affecting each other, so as to implement loose coupling between modules. However, this principle is also the most difficult to implement among the six design principles. If this principle is not implemented, it means that the open and closed principle (for extension development, for modification and closure) cannot be implemented.
Dependency inversion can be implemented in three ways.
1. Passing dependent objects through Constructors
For example, the parameters to be passed in the constructor are implemented through abstract classes or interfaces.
2. Pass the dependency object through the setter Method
That is to say, the parameter in the setXXX method we set is an abstract class or interface to implement the transfer of dependency objects.
3. Interface Declaration implementation dependency object
For example
Tu is a female monk

Public class Tutu {
// Paint a girl and cook noodles
Public void cook (Noodles noodles)
{
Noodles. eat ();
}
}
Noodles (only boiled noodles at present)

Public class Noodles {
// Noodles
Public void eat ()
{
System. out. println ("coated with noodles ...");
}
}
Tu tu sat at home to eat noodles (scenario)

Public class Home {
Public static void main (String args [])
{
Tutu tutu = new Tutu ();
Noodles food = new Noodles ();
Tutu. cook (food );
}
}
Running result: coated with noodles...
 
However, this is a problem. It is impossible to eat noodles every time. You can eat noodles every day. Therefore, in the cook method in the Tutu class above, wouldn't it be better if the coating would cook other foods. As a result, she took a step towards the housewife and used the Dependency inversion principle.
That is to say, you can also cook rice, fried squid (although not good, but delicious), shredded pork with soy sauce and so on. To implement it in code, you need to implement two interfaces: ITutu and IFood.

Public interface ITutu {
// This will make a lot of meals.
Public void cook (IFood food );
}
Implementation class

Public class Tutu implements ITutu {
 
@ Override
Public void cook (IFood food ){
Food. eat ();
}
 
}
Food Interface

Public interface IFood {
Public void eat ();
}
In this way, a lot of space is provided for the extension, and other classes are extended. The details will not change. In the future, you can learn what you want to learn.
Implement noodles

Public class Noodles implements IFood {
 
@ Override
Public void eat (){
System. out. println ("coated with noodles ...");
}
 
}
Rice

Public class Rice implements IFood {
 
@ Override
Public void eat (){
System. out. println ("tu eat rice (finally eat rice )...");
}
}
Scenario: you can eat it at home. Just do what you want.

Public class Home {
Public static void main (String args [])
{
// Interface makes it impossible to instantiate drops
ITutu tutu = new Tutu ();
// Instantiate the rice. You can eat rice after coating it.
IFood rice = new Rice ();
// Noodles
// IFood noodles = new Noodles ();
Tutu. cook (rice );
}
}
In this way, the implementation of various classes or modules is independent of each other and does not affect each other, thus realizing loose coupling between modules.

 

By Lou Lijun