Abstract class && Interface comparison

Comparison
ZZ from City Webclub

Abstract class and interface are two mechanisms that support the definition of abstract classes in the Java language, and it is because of the existence of these two mechanisms that Java is endowed with powerful object-oriented capabilities. Abstract class and interface have a great similarity in support of the definition of abstract classes, and can even be substituted for each other, so many developers are more relaxed about the choice of abstract class and interface when they are defining abstractions. In fact, there is a big difference between the two, for their choice even reflects the nature of the problem areas of understanding, the design of the intention to understand whether the correct and reasonable. This paper will analyze the differences between them and try to give developers a basis for choosing between them. Understanding abstract classes and interface are all used in the Java language for abstract classes (the abstract classes in this article are not translated from abstract class, which represents an abstract body, and abstract Class is a method for defining abstract classes in the Java language, which readers should be aware of to differentiate, so what is an abstract class, and what benefits can be derived from using abstract classes? In the object-oriented concept, we know that all objects are depicted by a class, but that is not the case in turn. Not all classes are used to depict objects, and if a class does not contain enough information to depict a specific object, such a class is an abstract class. Abstract classes are often used to characterize the abstract concepts that we analyze and design in the domain of problems, and are abstractions of a series of specific concepts that look different, but are essentially the same. For example: If we do a graphic editing software development, we will find that there are problems in the field of circles, triangles and some specific concepts, they are different, but they all belong to the shape of a concept, the concept of shape in the problem area does not exist, it is an abstract concept. It is because abstract concepts do not have specific concepts in the domain of the problem, so abstract classes that represent abstract concepts cannot be instantiated. In the object-oriented domain, abstract classes are primarily used for type concealment. We can construct an abstract description of a fixed set of behaviors, but this set of behaviors can have any possible concrete implementations. This abstract description is an abstract class, and any possible concrete implementations of this group represent all possible derived classes. A module can manipulate an abstract body. Because the module relies on a fixed abstraction, it can be disallowed, and by deriving from this abstraction, you can extend the function of the module. Readers familiar with OCP must know that abstract classes are the key to achieving one of the core principles of object-oriented design OCP (open-closed principle). From the languageInterpretation of abstract class and interface at the level of the law at the syntactic level, the Java language gives different definitions of the abstract class and interface, and the following is an example of how to define an abstract class named demo. The way to define a demo abstract class by using abstract class is as follows:

Abstract class Demo {abstract void method1 (); abstract void method2 (); ... ｝
The way to define a demo abstract class using interface is as follows:
Interface Demo {void method1 (); void Method2 ();}
In the abstract class approach, the demo can have its own data members, there can also be ABSTARCT member methods, and in the implementation of interface mode, the demo can only have static data members can not be modified (that is, must be static final , but no data members are generally defined in interface, all member methods are abstract. In a sense, interface is a special form of abstract class. From a programmatic point of view, abstract class and interface can be used to implement the idea of "design by contract". But there are some differences in the use of specific. First, abstract class represents an inheritance relationship in the Java language, and a class can only use one inheritance relationship at a time. However, a class can implement multiple interface. Perhaps this is a compromise of the Java language designer in considering Java's support for multiple inheritance. Second, in the definition of abstract class, we can give the default behavior of the method. But in the definition of interface, the method does not have the default behavior, and in order to circumvent this limitation, a delegate must be used, but this can add some complexity and sometimes cause a lot of trouble. There is another serious problem with the inability to define default behavior in an abstract class, which can cause maintenance problems. Because if you later want to modify the interface of the class (usually represented by abstract class or interface) to adapt to the new situation (for example, adding new methods or adding new parameters to the used methods can be very cumbersome and may take a lot of time (for a lot of derived classes , particularly so). However, if the interface is implemented through abstract class, it may be necessary to modify the default behavior defined in the abstract class. Similarly, if you cannot define the default behavior in an abstract class, it causes the same method implementation to appear in each derived class of the abstract class, violating the "one Rule,one place" principle, causing code duplication, which is also detrimental to future maintenance. Therefore, it is very careful to choose between the abstract class and the interface. From the perspective of design concept, abstract class and interface the difference between abstract class and interface is discussed from the point of view of syntax definition and programming, and the difference between these levels is comparatively low-level and not essential. This section is reflected in another dimension: abstract class and interfaceOut of the design concept, to analyze the difference between the two. The author thinks that from this level analysis can understand the essence of the two concepts. As already mentioned before, ABSTARCT class embodies an inheritance relationship in the Java language, and there must be an "is a" relationship between the parent class and the derived class in order for the inheritance relationship to be reasonable, that is, the parent class and the derived class should be the same in the conceptual nature (reference (3) for "is a" The relationship of the large length of in-depth discussion, interested readers can refer to. In the case of interface, it does not require that the interface and interface definitions be consistent in concept, but only to achieve the interface definition of the contract. To make the discussion easy to understand, the following is illustrated with a simple example. Consider an example that assumes that there is an abstract concept of door in our problem area that has two actions open and close, at which point we can define a type that represents that abstract concept by using abstract class or interface. The methods are defined as follows: Define door using the abstract class method:
Abstract class Door {abstract void open (); abstract void Close ();}
Define door using the interface method:
Interface Door {void open (); void close ();}
Other specific door types can be extends defined using the abstract class method door or implements interface defined using the door method. It seems like there's no big difference between using abstract class and interface. If you now require door also have the function of alarm. How do we design a class structure for that example (in this case, primarily to show the difference between the abstract class and interface reflected in the design idea, and to simplify or ignore other unrelated issues)? Here's a list of possible solutions, and analyze these different scenarios from the design concept layer. Solution One: Simply add a alarm method to the definition of door, as follows:
Abstract class Door {abstract void open (); abstract void close (); abstract void alarm ();}
Or
Interface Door {void open (); void close (); void alarm ();}
Then the Alarmdoor with alarm function is defined as follows:
Class Alarmdoor extends Door {void open () {.} void Close () {...} void alarm () {...}}}
Or
Class Alarmdoor implements Door {void Open () {.} void Close () {...} void alarm () {...}}}
This approach violates one of the core principles of object-oriented design ISP (Interface segregation priciple), in the definition of door, the door concept itself and the behavior of another concept "alarm" mixed together. One problem with this is that modules that rely solely on the concept of door will change as the concept of "alarm" changes (for example, by modifying the parameters of the alarm method), and vice versa. Solution Two: Since open, close, and alarm belong to two different concepts, they should be defined separately in an abstract class that represents both concepts, according to the ISP principle. The definitions are: Both concepts are defined using the abstract class method, both concepts are defined using the interface method, one concept is defined using the abstract class method, and the other is defined using the interface method. Obviously, since the Java language does not support multiple inheritance, it is not feasible to define both concepts using the abstract class method. The following two approaches are feasible, but their choice reflects the understanding of the conceptual nature of the problem area and the correctness and reasonableness of the reflection of the design intent. We Yi Yilai analysis and explanation. If both concepts are defined using the interface approach, then two questions are reflected: 1, we may not understand the problem area, Alarmdoor in the concept of the essence is door or alarm? 2, if we have no problem understanding of the problem areas, such as: we through the analysis of the problem area to find Alarmdoor in the concept of essentially and door is consistent, then we do not be able to realize the right to reveal our design intentions, This is not reflected in the definition of both concepts, which are defined using the interface approach. If our understanding of the problem domain is: Alarmdoor is inherently door in concept, it has the function of alerting. How do we design and implement to clearly reflect what we mean? As already mentioned, abstract class represents an inheritance relationship in the Java language, and an inheritance relationship is essentially an "is a" relationship. So for the concept of door, we should use the ABSTARCT class approach to define. In addition, Alarmdoor also has the function of alarm, which indicates that it can complete the behavior defined in the concept of alarm, so the concept of alarm can be defined by interface way. As shown below:
Abstract class Door {abstract void open (); abstract void Close ();} interface Alarm {void Alarm ();} Class Alarmdoor Ext Ends Door implements Alarm {void open () {...} void close () {...} void Alarm () {...}}
This way of implementation can basically clearly reflect our understanding of the problem area and correctly reveal our design intent. In fact, the abstract class represents the "is a" relationship, interface expressed the "like a" relationship, you can choose as a basis, of course, this is based on the understanding of the problem area, For example, if we think that Alarmdoor is essentially an alarm and has a door function, then the definition is reversed. Conclusion abstract class and interface are two ways to define abstract classes in the Java language, and there is a great similarity between them. However, their choices often reflect the understanding of the conceptual nature of the problem area and the correctness and reasonableness of the reflection of the design intent, as they represent different relationships between concepts (although they can achieve the functional requirements). This is in fact a kind of idiomatic method of language, hope that the reader friend can understand carefully.