China
DW China all content ............... DW China Technology Zone: Component Technology Java Technology Linux XML ............... DW China Special Topics: Safety Unicode Site Architecture ............... IBM full content search help IBM Home | Products & Services | Support & Download | Personalized Services
IBM: DeveloperWorks China website: Java: All articles
In-depth understanding Abstract Class and Interface
content:
Understand the abstract class From the grammatical definition level See Abstract Class and Interface From the Programming Level See Abstract Class and Interface From the Design Idea Level View Abstract Class and Interface Conclusion Reference About the author
Also in The Java Zone:
Teaching tools and product code and components all articles practical skills
Deng Hui, Sun Ming (DHUI@263.net)
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.
Understanding Abstract Class ABSTRACT CLASS and Interface are used in Java language (the abstract classes in this article are not translated from Abstract Class, which represents an abstract body, and Abstract Class is used in Java language for definition A method of abstract class, please pay attention to distinguish), then what is the benefit of using abstract classes? 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. From the syntax definition level, Abstract Class and Interface give a different definition method for Abstract Class and Interface in the syntax level, and the Java language gives different definitions, below to define an abstract class named DEMO as an example to illustrate this difference. Use the Abstract Class to define the way the Demo abstraction class is as follows: 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. For Abstract Class and Interface in the domination definition level, it is not the focus of this article, and will not be described again. Readers can refer to the reference [1] to obtain more related content. From the programming level to Abstract Class and Interface 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 defined 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. From the design concept level, Abstract Class and Interface mainly discusses the difference from Grammatical Definition 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 as follows: 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: Simple to 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 belong to two different concepts, depending on the ISP principle, they should be defined in the abstraction class representing the two concepts. 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 shown below: 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 () {...}
}
