In-depth understanding Abstract Class and Interface
City WebClub
Abstract Class and Interface are two mechanisms for the support of abstract class definitions in the Java language, which is due to the existence of these two mechanisms, which gives Java powerful object-oriented ability. Abstract Class and Interface have great similarities between support for abstract class definitions, even replaced with each other, so many developers are more casual for Abstract Class and Interface when performing abstract class definitions. In fact, there is still a big difference between the two. For their choice but even reflect the understanding of the nature of the problem, it is correct and reasonable for the understanding of the design intent. This article will analyze the differences between them, trying to provide the developer to provide a basis for choice between the two.
Understand abstract class
Abstract Class and Interface are used in the Java language (the abstract classes in this article are not translated from Abstract Class, which represents an abstract body, and Abstract Class is used to define abstract classes in Java languages. One way, please pay attention to distinguish the definition, then what is the benefit of the abstract class?
In the object-oriented concept, we know that all objects are drawn by classes, but it is not the case. Not all classes are used to draw objects, if there is no sufficient information in a class to depict a specific object, such a class is an abstract class. Abstract classes are often used to characterize our abstraction concepts in the design of the problem. The abstraction of the design is different, but the same concrete concept is in nature. For example, if we develop a graphic editing software, there will be a circle in the problem area, and there are some specific concepts such as the triangle, which are different, but they are in the shape of the shape, the shape of this concept is in the problem area. Present, it is an abstract concept. It is precisely because the concept of abstraction does not correspond to the specific concept in the problem area, so the abstract class used to characterize the abstraction concept is not instantiated.
In the object-oriented domain, the abstract class is mainly used to hide the type. We can construct an abstract description of a fixed set of behaviors, but this set of behavior can have any possible specific implementation. This abstract description is an abstraction class, and this group of any possible specific implementations are manifestative as all possible derived classes. The module can operate an abstract body. Since the module depends on a fixed abstraction, it can be modified; at the same time, the behavior function of this module can be extended by derived from this abstract body. Readers who are familiar with OCP must know that in order to enable the object-oriented design, the OCP (Open-Closed Princi), the abstract class is the key.
See Abstract Class and Interface from the syntax definition level
At the grammatical level, the Java language gives different definitions for Abstract Class and Interface, below to define an abstract class named DEMO as an example to illustrate this difference.
The way the Demo abstraction class is defined using the Abstract Class.
Abstract Class demo {
Abstract void method1 ();
Abstract void method2 ();
...
}
The way the Demo abstraction class is defined as the interfab is as follows:
Interface demo {
Void method1 ();
Void method2 ();
...
}
In the Abstract Class method, Demo can have its own data member, or there is a non-AbStarct member method, and in the implementation of the Interface mode, DEMO can only have static data members (which must be static final. However, in Interface generally does not define data members), all member methods are Abstract. In a sense, Interface is a special form of Abstract Class. From a programming perspective, Abstract Class and Interface can be used to implement the idea of "Design By Contract". But there are still some differences in specific use.
First, the Abstract Class represents a inheritance relationship in the Java language, and a class can only use one inheritance relationship. However, a class can implement multiple interface. Perhaps this is a collection of Java language designers who consider Java for multiple inheritance support.
Second, in the definition of Abstract Class, we can give the default behavior of the method. However, in the definition of Interface, the method cannot have default behavior. In order to bypass this limit, it must be entrusted, but this will increase some complexity and sometimes cause a lot of trouble.
There is another serious problem that cannot be defined in an abstract class, which may cause trouble on maintenance. Because if you want to modify the interface of the class (generally represented by Abstract Class or Interface) to accommodate new conditions (for example, add new methods or add new parameters to the used methods), it will be very troublesome. It may take a lot of time (especially the case, which is much more likely to derive.). However, if the interface is implemented by Abstract Class, it is possible to only need to modify the default behavior in the Abstract Class.
Similarly, if the default behavior cannot be defined in the abstract class, it will cause the same method to achieve the "One Rule, One Place" principle, causing the code repetition, which is equally not conducive to the principle of "One Rule, One Place" principle. Maintenance. Therefore, it is very careful when choosing between Abstract Class and Interface.
See Abstract Class and Interface from the design concept level
The above mainly discusses the difference from Abstract Class and Interface from the perspective of grammar definitions and programming. The difference between these levels is relatively low, non-essential. This section will analyze the difference between the two: Abstract Class and Interface reflected in the design concept reflected by the Abstract Class and Interface. The author believes that from this level, it can understand the essence of the concept.
As mentioned earlier, AbStarct Class reflects a inheritance in Java language. To make the inheritance relationship, "IS A" relationship must be present between the parent class and derived class, namely the parent class and derived class in the concept of the concept. It should be the same (reference [3] has an in-depth discussion about the "IS A" relationship, interested readers can refer to). For Interface, it is not required to implement the implementation of Interface and Interface definitions in nature, just a contract that implements the Interface definition. In order to make it easy to understand, the following will be described below.
Consider an example, assuming that there is an abstract concept about Door in our problem, which has two action Open and Close, which we can define a type indicating the abstraction concept through the Abstract Class or Interface. The definition method is shown below: Use the Abstract Class method to define DOOR:
Abstract class door {
Abstract void open ();
Abstract void close ();
}
Use the Interface mode to define DOOR:
Interface door {
Void open ();
Void close ();
}
Other specific DOOR types can use the Door or Implements defined using the Abstract Class method using the interface using the Interface mode. It seems that there is no big difference with Abstract Class and Interface.
If you now ask DOOR, you have to have alarm function. How do we design a class structure for this example (in this case, it is mainly to show the difference between Abstract Class and Interface reflected in the design concept, all other aspects have been simplified or ignored)? The possible solutions are listed below and analyze these different protocols from the design concept layer.
Solution 1:
Simply add an ALARM method in Door's definition, 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 definition of AlarmDoor with alarm function is as follows:
Class alarmdoor extends door {
Void open () {...}
void close () {...}
Void alarm () {...}
}
or
Class alarmdoor imports door {
Void open () {...}
void close () {...}
Void alarm () {...}
}
This method violates a core principle ISP (Interface SegRegation Principle) in object-oriented design, and mixing the behavior method inherent in the DOOR concept itself and another concept "alarm" behavior method is mixed together. One problem caused by this is that modules that only depend on the concept of door will change because of the change in the concept of "alarm" (such as: Modify the parameters of the Alarm method), and still.
Solution 2:
Since Open, Close and Alarm are two different concepts, according to ISP principles, they should be defined in an abstract class representing the two concepts, respectively. The definition method is: These two concepts use the Abstract Class method definition; both concepts use the interface mode definition; one concept uses the Abstract Class method definition, and the other concept is defined using the interface.
Obviously, since the Java language does not support multiple inheritance, two concepts are not feasible to use the Abstract Class method. The following two methods are feasible, but for their choice but reflect the understanding of the concept of the concept in the field, it is correct and reasonable for the design intent. Let us analyze and explain.
If the two concepts use the interface method to define, then two questions: 1. We may not understand the problem area, Alarmdoor is in the concept of Door or alarm? 2, if we have no problem in the understanding of the problem, for example, we have found that Alarmdoor is consistent with the concept of the problem, so we have no correctness in the realization, because In definitions of these two concepts (all defined using the Interface mode) reflects the above meanings. If we understand the problem of the problem is: AlarmDoor is in nature in nature, and it has a function of alarm. How should we design and implement it to clearly reflect our mean? As mentioned earlier, Abstract Class represents a inheritance relationship in the Java language, and inheritance relationship is essentially "IS A" relationship. So for the concept of Door, we should use the AbStarct Class to define. In addition, AlarmDoor has an alarm function indicating that it can complete the behavior defined in the alarm concept, so the alarm concept can be defined by the interface. As follows:
Abstract class door {
Abstract void open ();
Abstract void close ();
}
Interface alarm {
Void alarm ();
}
Class alarmdoor extends door imports alarm {
Void open () {...}
void close () {...}
Void alarm () {...}
}
This implementation is basically clearly reflected in our understanding of the problem area, and correctly reveals our design intent. In fact, Abstract Class said "Is A" relationship, Interface expressed "Like A" relationship, everyone can act as a basis when choosing, of course, this is based on understanding of the problem area, such as: if we think AlarmDoor The concept is essentially alarm, while also has DOOR's function, then the above definition method is to be reversed.
in conclusion
Abstract Class and Interface are two ways to define abstract classes in the Java language, and they have a lot of similarity. However, for their choice but often reflects the understanding of the concept of the concept in the field. For the design intent, it is correct, reasonable, because they behave different relationships between concepts (although it can achieve the functionality of demand). This is actually a usual method of language, I hope the reader friend can detain.
