This time, let you thoroughly understand interfaces and abstract classes

The purpose of this article is to discuss the role, examples and usage scenarios of abstract classes and interfaces, which is my understanding and summary. For more conceptual knowledge of interfaces and abstract classes, you can refer to the relevant documents yourself.

Abstract class, as the name suggests, is the abstraction of class. When we introduce the concept of object-oriented, we know that class is the abstraction of objective things, and abstract class is the further abstraction of class. How to understand them? For example, we define BMW, Mercedes Benz and Audi, and abstract BMW, Mercedes Benz and Audi respectively, Including relevant attributes and behaviors (i.e. methods). However, we know that cars have general attributes and behaviors, such as brand, engine, steering wheel, tire, forward, backward, steering, etc. Therefore, we can further abstract the abstract classes of "cars" on BMW, Mercedes Benz and other cars, including general features (properties and sides). Law) let BMW, Mercedes Benz and Audi inherit abstract classes to extend cars. They have the general characteristics of cars, and then define their own special properties and methods on the basis of abstract classes. Here, abstract class car is an abstract class. It can be seen that abstract classes are used to capture the general characteristics of subclasses, including properties and behaviors.

Let's take a look at the interface. If I develop a flying car called Bote Royce, its definition is as follows: Bote Royce system out. Println ("pretend to be able to fly ~"} looks OK: boteroyce extends car: express that this is a car; fly() method: reflect that this car can fly. However, with the development of technology, there are many manufacturers that can manufacture flying cars. Does every flying car define a fly () method? I thought it was not easy. I defined an abstract method Abstract void fly() in the abstract class car and let the subclass implement it. Isn't it OK? No, no, no... Not all milk is called trensu, not all cars can fly. Flying is not a general feature of cars. Defined in car The () method clearly violates the principle of using abstract classes to capture the general characteristics of subclasses. In this scenario, one of the solutions is to use the interface, as follows:} the definition of class boteroyce is modified as follows: boteroyce car system out. Println ("pretend to be able to fly ~"} other brands of flying cars can realize the flight capability through the extensions car implements aircraft. The interface aircraft defined above is the interface, and we usually use the interface to abstract the behavior.

The difference between the two can be further understood in combination with the previous examples. An abstract class is an abstraction of the nature of the class and expresses the relationship between is a, such as BMW is a car. Abstract classes contain and implement the general characteristics of subclasses, abstract the differentiated characteristics of subclasses, and hand them over to subclasses for implementation. The interface is the abstraction of behavior and expresses the relationship of like a. For example, Bote Royce like a aircraft (it can fly like an aircraft), but it is essentially a car. The core of the interface is to define the behavior, that is, what the implementation class can do. The interface doesn't care who the implementation class subject is and how it is implemented.

Students familiar with Java may doubt that the above interfaces can be used by re extracting care: flycar} ordinary cars are still extended cars, and flying cars are extended flycar: boteroyce system out. Println ("pretend to be able to fly ~"} if you think so, it means you get to the point of the abstract class. But then, isn't the interface meaningless? Of course not. As far as boteroyce is concerned, if you are concerned about the whole "flying car", defining the abstract class flycar is a good choice; if you are concerned about the car's ability For the "flying" behavior, you might as well continue to use the previous scheme using the aircraft interface. This is consistent with one of the six principles in design patterns - Richter replace Principle - consistent, This principle stipulates that all references to the base class (abstract class or interface) must be transparent when using the objects of its subclasses. That is, when you follow this principle, you must consider whether you care about the "flying car" entity or the "flying car" behavior, and use it as the base class to determine the acceptable subclass objects of the program. At the same time, the "interface isolation principle" It guides us that the dependence of one class on another should be based on the smallest interface. Compared with the abstract class flycar, the interface aircraft can minimize the exposed interfaces and hide the details, which is more in line with this principle. Therefore, object orientation only guides our programming, not the idea of rules and rules. In actual development, the use of abstract classes or interfaces is not absolutely limited, but depends on your business scenario and architecture design.

Well, this is the summary of interfaces and abstract classes. Do you fully understand?