interface-oriented programming and implementation-oriented programming
Recently read the four-person group's classic masterpiece, "Design patterns reusable Object-oriented software," a book, to take notes and thinking in the form of blogs
The principle of reusable object-oriented design is mentioned in the book, and the first principle is:
Programming for interfaces, not for implementation
In fact, in the use of object-oriented language programming, often inadvertently will involve the knowledge mentioned in the book, but once the special vocabulary to describe the first reaction is "eh." What does that mean. Don't understand Ah ", only after repeated reading and thinking, realize that this is a common problem of daily programming, and get a deeper understanding of the implementation of programming
For example, assume that there are two brands of tires, Bridgestone (Bridgestone) and Michelin (Michelin), and the common characteristics of tires will turn (roll). Then we can get two classes:
Class Bridgestone {public
void Roll () {
System.out.print ("Bridgestone is rolling.");
}
}
Class Michelin {public
void Roll () {
System.out.print ("Michelin is Rolling");
}
}
For a car with a Bridgestone tyre, the turning of the car is the rotation of the tyre:
Class Car {public
void Roll (Bridgestone tire) {
tire.roll ()
}
}
What if I had a Michelin-starred tyre?
Car car = new car ();
Michelin tire = new Mechilin ();
Car.roll (tire);
Obviously, the program will go wrong. This is implementation-oriented programming, where variables are directed to instances of a particular class.
This strong dependency will greatly inhibit the flexibility and reusability of the programming. interface-Oriented programming
If the common characteristics of the two tires are extracted, when turning the tires, only focus on the "tire" itself, and not to understand "what brand tires", the problem is solved
Interface Tire {public
void roll ();
}
Class Bridgestone implements Tire {public
void Roll () {
System.out.print ("Bridgestone is rolling.");
}
class Michelin implements Tire {public
void Roll () {
System.out.print ("Michelin is Rolling");
}
}
Interface Tire defines the "turn" interface, but delays the implementation to subclasses
Class Car {public
void Roll (Tire Tire) {
tire.roll ()
}
}
Car car = new car ();
BridgeStone tire1 = new BridgeStone ();
Michelin tire2 = new Mechilin ();
Car.roll (tire1);
Car.roll (Tire2);
When the car is turning, it does not pay attention to "what brand tires", only focus on "tires", how to turn on how to turn
As we can see from this example, interface-oriented programming features:
Customers do not need to know the specific type of object they use, only the object has the interface that the customer expects
When a customer uses a car to rotate a tyre, it is not necessary to know the specific type of tyre (brand, sub-category), as long as the tyre has the desired interface (roll) of the customer.
Customers don't need to know what kind of objects they use, they just need to know the abstract class that defines the interface.
When a customer uses car's roll method to call a tyre-corresponding method, it does not need to know what subclass of the tyre instance is being implemented, and he only needs to know the content of the abstract class (interface in Java ) that defines the rotation method.
Interface-oriented programming is a principle of object-oriented design, using this kind of programming idea, we can easily write reusable code, which is very helpful to the understanding and maintenance of code.