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.
The way the Demo abstraction class is defined as follows: abstract void method1 (); Abstract void method1 (); Abstract void method2 (); ...} Using Interface Declining the Demo Abstract Class: Interface Demo {Void Method1 () In the Abstract Class method, Demo can have its own data member, or there is a non-AbStarct member method, and Demo can only have static data that cannot be modified in the implementation of the interfab mode. Members (that is, Static Final, but 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 shown below: Use the Abstract Class to define the DOOR: Abstract Class Door {Abstract Void Open (); Abstract Void Close ();} Using the Interface Mode Defining DOOR: Interface Door {Void Open (); void close (); } Other specific DOOR types can use the Door or Implements defined using the Abstract Class mode to define DOORs 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 in Door's definition adds an Alarm method as follows: Abstract Class dire {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 Priciple) in object-oriented design, in Door The behavior method inherent in the DOOR concept itself is mixed with the behavior method of the DOOR concept itself and another concept "alarm". 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.
