Dependency inversion principle in JAVA
One of the most basic principles of American law is "everyone is equal." We don't care what kind of struggle or bloodshed it was achieved through. We only understand it as a JAVA method, which is defined as follows:
public final boolean everyone is equal(person 1, person 2){
return true;
}
Although the laws of each state may be different, such as the Basic Law of the United States, New York may be called the New York Basic Law. They should have such a relationship: the New York Basic Law inherits the Basic Law of the United States, but does not allow rewriting of this method.
When it comes to enforcement in New York, the following are used:
Basic Law of the United States = new New York Basic Law
Calling the "everyone is equal" method anywhere will return "true", which means that the principle of everyone's equality cannot be changed anywhere. This is a macro decision that determines the micro, and it will not change between men and women because of New York. Women's inequality.
For example, a certain country also has a basic law and a method of equality for all. The definition should be as follows:
public boolean everyone is equal(person 1, person 2){
return true;
}
For example, a certain place in a certain country also has a basic law. The basic law of a certain place is also inherited from the basic law of a certain country. However, because the method of "everyone is equal" is not final, it may be rewritten. When implemented in a certain place, it may be:
Basic Law of a certain country = new Basic Law of a certain place
or
Basic Law of a certain place = new Basic Law of a certain place
Maybe when the Basic Law of a certain place inherited the Basic Law of a certain country, the method "everyone is equal" was rewritten and changed to:
public boolean everyone is equal(person 1, person 2){
if(person 1==person from a certain place&& person 2==person from a certain place){
if(person 1 and person 2 have the same attributes){
if(person 1 and person 2 are the same except that they are not the same person){
if(no one else happens){
return true;
}else{
return false;
}
}else{
return false;
}
}else{
return false;
}
}else{
return false;
}
}
Let's talk about the dependency inversion principle, according to "JAVA and Patterns":
The abstract level contains the business logic of the application system and macro-level strategic decisions that are important to the entire system and is a reflection of inevitability; while the concrete level contains some minor implementation-related algorithms and logic, as well as tactical The decision involves considerable chance. Specific levels of code will change frequently, and errors cannot be avoided. The level of abstraction depends on the level of concreteness. Algorithm changes using details at the specific level immediately affect the macroscopic business logic at the abstraction level, causing the microscopic to determine the macroscopic, tactics to determine the strategy, and chance to determine necessity. This is ridiculous.
After reading this, you will understand why you should use it more often when writing code in the future:
abstract logic = new concrete logic
Use as little as possible:
specific logic = new specific logic
This is the interface-oriented programming that is currently advocated. Here is another practical example of interface-oriented programming:
You should usually use List more often. List itself is an interface inherited from Collection. You can use it like this:
List list=new Vector();
The List declared in this way is actually a Vector type, because Vector is its subclass. According to the Liskov substitution principle, subclasses can be accepted wherever the parent class can be accepted. At this time, the List is synchronized, and of course it will be affected by certain performance. If you change to an environment that does not require synchronization in the future, you only need to change the above code to something like this:
List list=new ArrayList();
No other code needs to be modified. The actual type of List at this time is ArrayList.
From this point, we can see why interface-oriented programming is cherished by designers, because after they provide the interface, the implementers implement specific classes based on the interface, and there is no need to worry about the implementers destroying the integrity of the original program, and the designers will never Only care about the methods in the interface, don't worry about the auxiliary methods in the concrete class. But this comes at an additional cost, such as adding JAVA classes. If abstract classes can bring less efficiency, it is a better choice to use concrete coupling, such as tool classes.