The difference between a "go" Java Interface and an abstract class

1. The difference between abstract classes and interfaces

The so-called abstract class is used to characterize our analysis in the problem domain, the abstract concept of design, is a series of seemingly different, but essentially the same specific concept of abstraction; the so-called interface, the equivalent of a power outlet, pluggable components equivalent to electrical appliances. The key to pluggable artifacts is that there is a common interface and that each component implements this interface. Interface is the key to realize the pluggable nature of the component.

1.1. Distinguish abstract classes and interfaces from the syntax layer

From the syntactic level, the Java language gives different definitions for abstract classes and interfaces, and the following is an example of defining an abstract class called Demo to illustrate this difference.

The demo abstract class is defined in the following way:

Abstract class Demo {

abstract void method1 ();

abstract void method2 ();

...

}

The demo interface is defined in the following way:

Interface Demo {

void Method1 ();

void Method2 ();

...

}

In the definition of abstract class, the demo can have its own data members, but also can have non-abstract member methods, and in the definition of the interface, the demo can only have static final data members, all the member methods are abstract. In a sense, an interface is a special form of abstract class.

From a programmatic point of view, first of all, abstract classes and interface inheritance rules are different, abstract only allow single inheritance, and a class can implement multiple interfaces. Interface for the support of multiple inheritance; second, in the definition of an abstract class, the default behavior of the method can be given, whereas in the definition of an interface, the method cannot have the default behavior, the delegate must be used, and in a sense, the interface is more abstract than the abstract class.

1.2. Understanding abstract classes and interfaces from the design layer

The above mainly from the point of view of the grammatical layer of the abstract class and interface, the difference between these levels is relatively low-level, non-essential. This section will analyze the nature of the concepts from this design layer.

Abstract classes embody an inheritance relationship in the Java language, in order to make the inheritance relationship reasonable, there must be a "is-a" relationship between the parent class and the derived class, that is, the parent and subclass should be the same in nature. In the case of interfaces, the interface does not require that the implementation and interface definitions are inherently consistent in concept, but only the contract that implements the interface definition. Consider an example where, assuming there is an abstract concept about door, 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 means of an abstract class or interface, as follows:

Door abstract classes are defined in the following way:

Abstract class Door {

abstract void open ();

abstract void close ();

}

The interface of the door is defined in the following way:

Interface Door {

void Open ();

void Close ();

}

Other specific door types can be extends using door defined by an abstract class or implements door defined using an interface method. It seems that there is no big difference between using abstract classes and interfaces. If you now require door also have the function of alarm. The possible solutions are listed below, and the scenarios are analyzed from the design level.

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 method violates the principle of interface isolation, and in the definition of door, it mixes the behavior method inherent in the door concept with another concept of "alarm". 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, based on the principle of interface isolation. These two concepts are defined using an abstract class approach, both of which are defined using an interface approach, one that is defined using an abstract class approach, and another that is defined using an interface approach.

Obviously, because the Java language does not support multiple inheritance, it is not feasible for both concepts to be defined using abstract class methods. 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.

If both concepts are defined using an interface approach, two questions are reflected: first, we may not understand the problem areas clearly, alarmdoor the concept is essentially door or alarm? Second, if we have no problem with our understanding of the problem areas, for example: we find that Alarmdoor is consistent in concept and door by analysis of the problem domain, then we do not have the right to reveal our design intent when we implement it. Because the definitions of both concepts, which are defined using interface methods, do not reflect the above meanings.

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 classes represent an inheritance relationship in the Java language, and the inheritance relationship is essentially a "is-a" relationship. So for the concept of door, we should use the abstract 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 method. As shown below:

Abstract class door{

abstract void open ();

abstract void close ();

}

Interface alarm{

void Alarm ();

}

Class Alarmdoor extends Door implements alarm{

void Open () {...}

void Close () {...}

void alarm () {...}

}

This kind of realization basically can clearly reflect our understanding of the problem area, and reveal our design intention correctly. In fact, the abstract class represents the "is-a" relationship, interface represents the "has-a" relationship, in the choice can be used as a basis, of course, this is based on the understanding of the problem areas, such as: if we believe that alarmdoor in the concept is essentially an alarm, but also has Door function, then the above definition will be reversed.

2. The importance of abstract mechanisms

Abstract mechanism is the necessary condition of object-oriented reusable design.

The cornerstone of object-oriented reusable design is the open-close principle, that is, a software entity should be opened for expansion and closed for modification. The key to meeting the opening and closing principle is abstraction. In an object-oriented programming language such as Java, a system can be defined as an abstract design that is not changed once and for all, and this design allows endless behavior to be implemented at the implementation level. In the Java language, you can give one or more abstract classes or interfaces that specify all of the possible extensions, so that they do not change in any extended case. This makes the system's abstraction layer do not need to modify, thus satisfies the opening and closing principle of the second article: the modification is closed. At the same time, because the export of one or more new concrete classes from the abstraction layer can change the behavior of the system, so the system is open to the extension, which satisfies the opening and closing principle of the first: open to the expansion.

All software systems have a common nature, that is, the demand for them will change over time, the design of the system must be stable in the face of new requirements of the software system. The design which satisfies the opening and shutting principle can bring some adaptability and flexibility to the software system, and make the software system of change have certain stability and continuity.

3. Conclusion

Abstract classes and interfaces are two ways of defining abstract classes in the Java language, and there is a great similarity between them. However, the choice of them often reflects the understanding of the conceptual nature of the problem areas, the correctness and reasonableness of the design intent, as they represent the different relationships between the concepts. Only by correctly understanding object-oriented design principles and using abstract classes and interfaces flexibly can we design an easy-to-use system

The difference between a "go" Java Interface and an abstract class