The difference between abstract class and interface in object-oriented design

In Ood (object-oriented design), abstract classes or interfaces are often used, "note: in C + +, there is no concept of interfaces, only abstract classes, and both exist in Java." In the process of use, there may be many people think that the interface and abstract class is similar, and then think of course that can be completely replaced with each other. In fact, although they have a lot of similarities, there are also big differences.

　　1. Conditions for the occurrence of abstract classes and interfaces

In object-oriented concepts, we know that all objects are depicted through classes, but not in the opposite way. 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 we derive from analysis and design of problem areas, and are abstractions of a series of concrete concepts that look different, but are essentially the same.

For example, if we develop a graphical editing software, we will find that there are some specific concepts of circle and triangle in the problem domain, they are different, but they all belong to the concept of shape, the concept of shape does not exist in the problem domain, it is an abstract concept. Abstract classes used to characterize abstract concepts cannot be instantiated because abstract concepts have no corresponding specific concepts in the problem domain.

Abstract classes are primarily used for type concealment in the object-oriented realm. We can construct an abstract description of a fixed set of behaviors, but this group of behaviors can have any possible concrete implementation. This abstract description is an abstract class, and any possible concrete implementation of this group is represented by all possible derived classes. The module can manipulate an abstract body. Because the module relies on a fixed abstraction, it can be modified, and the behavior of this module can be extended by deriving from this abstraction. Readers familiar with OCP must know that abstract classes are key in order to achieve a core principle OCP (open-closed Principle) for object-oriented design.

　2. Distinguish the abstract class and interface from the syntax definition hierarchy

At the syntactic level, the Java language gives different definitions for abstract class and interface, and the following is an example of defining an abstract class called Demo to illustrate this difference. The way to define the demo abstract class using the abstract class is as follows:

Abstract class demo_a {    abstractvoid  method1 ();         Abstract void method2 ();        ...   }

The way to define the demo abstract class using interface is as follows:

Interface demo_i {     void  method1 ();         void method2 ();        ...    }   

In the abstract class mode, the demo can have its own data members, but also can have non-ABSTARCT member methods, and in the implementation of interface mode, the demo can only have static, cannot be modified data members (that is, must be static Final, but generally does not define data members in interface, all member methods are abstract. In a sense, interface is a special form of abstract class.

From a programmatic point of view, both the abstract class and the interface can be used to implement the idea of "design by contract". However, there are some differences in the specific use.

First, the abstract class represents an inheritance relationship in the Java language, and a class can only use one inheritance relationship at a time. But 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 method the default behavior. However, in the definition of interface, the method cannot have the default behavior. in order to circumvent this restriction, delegates must be used, but this adds some complexity and can 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 headaches. Because if you later want to modify the class (typically represented by an abstract class or interface) to accommodate the new situation (for example, adding new methods or adding new parameters to a used method), it can be very cumbersome and may take a lot of time (for many of the derived classes, This is particularly true). But if it is done by the abstract class, it is possible to simply modify the default behavior defined in the abstract class.

Similarly, if the default behavior cannot be defined in an abstract class, it causes the same method implementation to appear in each of the derived classes of the abstract class, violating the "one Rule,one place" principle, resulting in code duplication, which is also detrimental to future maintenance. Therefore, you should be very careful when choosing between the abstract class and the interface.

3. Distinguish between abstract class and interface from the design concept level

It mainly discusses the difference between abstract class and interface from the angle of grammar definition and programming, and the difference between these layers is comparatively low-level and non-essential. The next step is to analyze the difference between the two, from the design concepts reflected in the abstract class and interface. Analysis from this level can better understand the nature of the two concepts.

As mentioned earlier, ABSTARCT class embodies an inheritance relationship in the Java language, in order to make the inheritance relationship reasonable, there must be an "is a" relationship between the parent class and the derived class, that is, the parent class and the derived class should be the same in nature. For interface, it does not require that the interface and interface definitions be consistent in the concept, but only the contract that implements the interface definition. To make the discussion easy to understand, a simple example is described below.

Consider an example of the assumption that there is an abstraction about door in our problem area, that the door has the ability to execute two actions open and close, at which point we can define a type that represents the abstract concept by either an abstract class or a interface. The definitions are as follows:

Define door using the abstract class method:

Abstract class door_a {        abstractvoid  open ();         Abstract void close ();  }  

Define door using the interface method:

Interface Door_i {        void  open ();         void close ();    }  

other specific door types can be extends using the door defined by the abstract class or implements interface defined using door mode. It seems that there is no big difference between using abstract class and interface.

If you now require door also have the function of alarm. How do we design the class structure for this example (in this case, mainly to show the difference between the abstract class and the interface reflected in the design concept, the other unrelated issues are simplified or omitted), the possible solutions are listed below. And from the design concept layer to face these different scenarios for analysis.

　　Solution One : Simply add a alarm method to the definition of door, as follows:

Abstract class door_a {        abstractvoid  open ();     Abstract void close ();     Abstract void

Or:

Interface Door_i {        void  open ();         void close ();         void alarm ();      }  

Then the Alarmdoor with alarm function is defined as follows:

class extends door_a {        void  open () {...}         void Close () {...}         void alarm () {...}   

Or:

class Implements Door_i {       void  open () {...}         void Close () {...}     void alarm () {...}}

This approach violates a core principle in object-oriented design ISP (Interface segregation priciple), which mixes the behavior method inherent in door concept with another concept of "alarm" in the definition of door. One problem is that modules that rely solely on the concept of door are changed by the concept of "alarm" (e.g., 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. These two concepts are defined using the abstract class approach, both of which are defined using the interface method, one defined using the abstract class approach, and the other defined using the interface method.

Obviously, because the Java language does not support multiple inheritance, it is not feasible for both concepts to be defined using the abstract class method. The latter two methods are feasible, but the choice of them reflects the understanding of the conceptual nature of the problem domain and the correctness and reasonableness of the design intent. We hit analysis, explain.

If both concepts are defined using the interface method, two questions are reflected:

1, we may not understand the problem areas clearly, alarmdoor in the concept is essentially door or alarm?

2. If our understanding of the problem area is not problematic, for example: we find that Alarmdoor is consistent in concept in nature and door by analysis of the problem domain, then we do not have the ability to properly disclose our design intent when we implement it, because the definitions of both concepts are used interface method definition) does not reflect the above meaning.

If our understanding of the problem area is: Alarmdoor is inherently door in concept, and it has a 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, whereas an inheritance relationship is essentially an "is a" relationship. So for the door concept, we should use the ABSTARCT class approach to define it. In addition, Alarmdoor also has the alarm function, indicating that it can complete the alarm concept defined behavior, so the alarm concept can be defined by the interface way. As shown below:

Abstract classdoor_a {Abstract voidopen (); Abstract voidclose ();}InterfaceAlarm {voidAlarm (); } classAlarmdoorextendsDoorImplementsAlarm {voidopen () {...} voidClose () {...} voidalarm () {...} }

This kind of realization basically can clearly reflect our understanding of the problem area, and reveal our design intention correctly. In fact, abstract class represents the "is a" relationship, interface represents a "like a" relationship, you can choose as a basis, of course, this is based on the understanding of the problem areas, For example: If we think that alarmdoor in the concept is essentially an alarm, but also has the function of door, then the definition of the above method will be reversed.

Abstract class and interface are two of the ways in which abstractions are defined in the Java language, and there is a great similarity between them. However, their choices often reflect an understanding of the nature of the concepts in the problem domain, the correctness and reasonableness of the design intent, as they represent the different relationships between concepts (though they are capable of fulfilling the function of demand). This is actually a kind of language of the customary law.

Finally, summarize the usage and differences of the abstract class and interface in a few short ways:

1, abstract classes and interfaces can not be directly instantiated. If you are instantiating, the abstract class variable must point to a subclass object that implements all the abstract methods, and the interface variable must point to the class object that implements all the interface methods.

2, abstract class to Quilt class inheritance, interface to be class implementation.

3, interface can only do method declaration, abstract class can do method declaration, can also do the default implementation of the method.

4, the variables defined in the interface can only be public static constants, the variables in the abstract class are ordinary variables.

5, abstract class in the abstract method must be all the quilt class implementation, if the child class can not fully implement the parent class abstract method, then the subclass is still abstract class. Similarly, when a class implements an interface, if the interface method cannot be fully implemented, then the class can only be an abstract class.

6, abstract class can have no abstract method

7, if there is an abstract method in a class, then this class can only be abstract class

8, abstract methods to be implemented, so can not be static, nor can it be private.

9, the interface can inherit the interface, and can inherit the interface, but the class can only single-inherit "note: Here is the Java syntax." You can inherit more in C + +.

In particular, for the common implementation code, the abstract class has its advantages. Abstract classes can guarantee the hierarchical relationship of implementation and avoid duplication of code. However, even when using abstract classes, it is important not to overlook the principle of defining behavior models through interfaces. From a practical point of view, if you rely on abstract classes to define behavior, it often leads to overly complex inheritance relationships, and it is more efficient to separate behaviors and implementations through interface definition behavior, which facilitates the maintenance and modification of code.

Reference documents:

[1]. Abstract class

[2]. Java Enhancement (iv)-----Abstract classes and Interfaces

[3]. Deep understanding of Java interfaces and abstract classes

[4]. The difference between an abstract class and an interface

The difference between abstract class and interface in object-oriented design