Thinking about interfaces and abstract classes 2.0

1. Differences at the grammatical level

Abstract classes can provide the implementation details of member methods, while only public abstract methods can exist in interfaces (of course there are default instance methods, static methods, etc.);

Member variables in an abstract class can be of various types, while member variables in an interface can only be of public static final type;

A class can only inherit from one abstract class, but a class can implement multiple interfaces.

Second, the difference in design level

1) An abstract class is an abstraction of a thing, that is, an abstraction of a class, while an interface is an abstraction of behavior.

An abstract class abstracts the entire class as a whole, including attributes and behaviors, but an interface abstracts the parts (behaviors) of the class.

To give a simple example, airplanes and birds are different things, but they all have one thing in common, that is, they can fly. Then when designing, you can design an airplane as an Airplane-like, and a bird as a Bird-like, but you can’t design the feature of flight as a class, so it’s just a behavioral feature, not an abstract description of a class of things. . At this time, the flight can be designed as an interface Fly, including the method fly( ), and then Airplane and Bird implement the Fly interface according to their own needs. Then as for different types of aircraft, such as fighter jets and civil aircraft, it is enough to directly inherit from Airplane. The same is true for birds. Different types of birds can directly inherit from the Bird class. It can be seen from here that inheritance is a "whether" relationship, while interface implementation is a "whether there is" relationship. If a class inherits a certain abstract class, the subclass must be the type of the abstract class, and the interface implementation is related to whether it has or not, such as whether the bird can fly (or whether it has the characteristic of flying), can fly Then you can implement this interface, if you can’t fly, don’t implement this interface.

2) The design level is different. As the parent class of many subclasses, the abstract class is a template design. While the interface is a behavior specification, it is a radial design. What is template design? The simplest example, everyone has used the template in ppt. If you use template A to design ppt B and ppt C, the common part of ppt B and ppt C is template A. If their common part needs to be changed, you only need to change it Template A is fine, and there is no need to make changes to ppt B and ppt C again. And the radial design, for example, a certain elevator is equipped with some kind of alarm, once the alarm is to be updated, all of them must be updated. That is to say, for an abstract class, if you need to add a new method, you can directly add a specific implementation in the abstract class, and the subclass does not need to be changed; but for the interface, if the interface is changed, all implementations of the interface Classes must be modified accordingly.

Let's analyze the example of door and alarm: the door has two actions of open( ) and close( ), at this time we can define this abstract concept through abstract classes and interfaces:

1. abstract class Door {  

1.    

1.     public abstract void open();  

1.    

1.     public abstract void close();  

1.    

1. }  

or:

1. interface Door {  

1.    

1.     public abstract void open();  

1.    

1.     public abstract void close();  

1.    

1. } 

But now if we need the door to have the function of alarm( ), how to realize it? Here are two ideas:

1) Put these three functions in the abstract class, but in this way, all subclasses inherited from this abstract class have the alarm function, but some doors do not necessarily have the alarm function;

2) Put all these three functions in the interface. The class that needs to use the alarm function needs to implement the open( ) and close( ) in this interface. Maybe this class does not have open( ) and close( ) at all. Two functions, like a fire alarm.

It can be seen from here that the open(), close() and alarm() of Door belong to two different categories of behaviors. open() and close() belong to the inherent behavior characteristics of the door itself, while alarm() belongs to Extended additional behavior. Therefore, the best solution is to design the alarm as an interface separately, including the behavior of alarm(), and design Door as a separate abstract class, including two behaviors of open and close. Then design an alarm door to inherit the Door class and implement the Alarm interface.

1. interface Alram {  

1.    

1.     void alarm();  

1.    

1. }  

 6. abstract class Door {     

1.     void open();  

1.    

1.     void close();  

1.    

1. }  

1.    

1. class AlarmDoor extends Door implements Alarm {  

1.    

1.     void oepn() {  

1.       //....  

1. ​    }  

1.    

1.     void close() {  

1. ​      //....  

1.     }  

1.    

1.     void alarm() {  

1.       //....  

1.     }  

1. }