Detailed parsing of the differences between abstract classes and interfaces in Java _java

In the Java language, abstract class and interface are two mechanisms that support the definition of abstract classes. It is because of the existence of these two mechanisms that gives Java a powerful object-oriented ability. Abstract class and interface have a great similarity in support of the definition of abstract classes, and can even be substituted for each other, so many developers are more relaxed about the choice of abstract class and interface when they are defining abstractions. In fact, there is a big difference between the two, for their choice even reflects the nature of the problem areas of understanding, the design of the intention to understand whether the correct and reasonable. This paper will analyze the differences between them and try to give developers a basis for choosing between them.

Understanding Abstract Classes

Abstract class and interface are all used in the Java language for abstract classes (the abstract classes in this article are not translated from abstract class, which represents an abstract body, and abstract Class is a method for defining abstract classes in the Java language, which readers should be aware of to differentiate, so what is an abstract class, and what benefits can be derived from using abstract classes?

In the object-oriented concept, we know that all objects are depicted by a class, but that is not the case in turn. 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 that we analyze and design in the domain of problems, and are abstractions of a series of specific concepts that look different, but are essentially the same. For example: If we do a graphic editing software development, we will find that there are problems in the field of circles, triangles and some specific concepts, they are different, but they all belong to the shape of a concept, the concept of shape in the problem area does not exist, it is an abstract concept. It is because abstract concepts do not have specific concepts in the domain of the problem, so abstract classes that represent abstract concepts cannot be instantiated.

In the object-oriented domain, abstract classes are primarily used for type concealment. We can construct an abstract description of a fixed set of behaviors, but this set of behaviors can have any possible concrete implementations. This abstract description is an abstract class, and any possible concrete implementations of this group represent all possible derived classes. A module can manipulate an abstract body. Because the module relies on a fixed abstraction, it can be disallowed, and by deriving from this abstraction, you can extend the function of the module. Readers familiar with OCP must know that abstract classes are the key to achieving one of the core principles of object-oriented design OCP (open-closed principle).

viewing abstract class and interface from the perspective of grammatical definition

At the syntactic level, the Java language gives different definitions of the abstract class and interface, and the following is an example of how to define an abstract class named demo.

The way to define a demo abstract class by using abstract class is as follows:

Copy Code code as follows:

Abstract class demo{
abstract void method1 ();
abstract void method2 ();
...
｝

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

Copy Code code as follows:

Interface demo{
void Method1 ();
void Method2 ();
...
}

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

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

First, the abstract class represents an inheritance relationship in the Java language, and a class can use only one inheritance relationship (because Java does not support multiple inheritance--a note). However, 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 default behavior of the method. But in the definition of interface, the method does not have the default behavior, and in order to circumvent this limitation, a delegate must be used, but this can add some complexity and 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 problems. Because if you later want to modify the interface of the class (usually represented by abstract class or interface) to adapt to the new situation (for example, adding new methods or adding new parameters to the used methods can be very cumbersome and may take a lot of time (for a lot of derived classes , particularly so). However, if the interface is implemented through abstract class, it may be necessary to modify the default behavior defined in the abstract class.

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

viewing abstract class and interface from the perspective of design concept

The above mainly discusses the difference between abstract class and interface from the point of view of syntax definition and programming, the difference between these levels is comparatively low-level and not essential. This section will look at the difference between the two in terms of the design concepts reflected in the abstract class and interface. The author thinks that from this level analysis can understand the essence of the two concepts.

As mentioned earlier, abstract class embodies an inheritance relationship in the Java language, and in order for inheritance to be reasonable, there must be a "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 the conceptual nature. In the case of interface, it does not require that the interface and interface definitions be consistent in concept, but only to achieve the interface definition of the contract. To make the discussion easy to understand, the following is illustrated with a simple example.

Consider an example that assumes that there is an abstract concept of door in our problem area that has two actions open and close, at which point we can define a type that represents that abstract concept by using abstract class or interface. The methods are defined as follows:

Define door using the abstract class method:

Copy Code code as follows:

Abstract class door{
abstract void open ();
abstract void close ();
}

Define door using the interface method:

Copy Code code as follows:

Interface door{
void Open ();
void Close ();
}

Other specific door types can be extends defined using the abstract class method door or implements interface defined using the door method. It seems like there's no big difference between using abstract class and interface.

If you now require door also have the function of alarm. How do we design a class structure for that example (in this case, primarily to show the difference between the abstract class and interface reflected in the design idea, and to simplify or ignore other unrelated issues)? Here's a list of possible solutions, and analyze these different scenarios from the design concept layer.

Solution One:

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

Copy Code code as follows:

Abstract class door{
abstract void open ();
abstract void close ();
abstract void alarm ();
}

Or

Copy Code code as follows:

Interface door{
void Open ();
void Close ();
void Alarm ();
}

Then the Alarmdoor with alarm function is defined as follows:

Copy Code code as follows:

Class Alarmdoor extends door{
void Open () {...}
void Close () {...}
void alarm () {...}
}

Or

Copy Code code as follows:

Class Alarmdoor implements door{
void Open () {...}
void Close () {...}
void alarm () {...}
｝

This approach violates one of the core principles of object-oriented design ISP (Interface segregation principle), in the definition of door, the door concept itself and the behavior of another concept "alarm" mixed together. One problem with this is that modules that rely solely on the concept of door will change as the concept of "alarm" changes (for example, by 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. The definitions are: Both concepts are defined using the abstract class method, both concepts are defined using the interface method, one concept is defined using the abstract class method, and the other is defined using the interface method.

Obviously, since the Java language does not support multiple inheritance, it is not feasible to define both concepts using the abstract class method. The following two approaches are feasible, but their choice reflects the understanding of the conceptual nature of the problem area and the correctness and reasonableness of the reflection of the design intent. We Yi Yilai analysis and explanation.

If both concepts are defined using the interface approach, then two questions are reflected: 1, we may not understand the problem area, Alarmdoor in the concept of the essence is door or alarm? 2. If we have no problem with the understanding of the problem area, for example: we find that Alarmdoor is consistent with the concept in essence and door by analysis of the problem area, then we do not have the right to reveal our design intention when we implement it, because in the definition of these two concepts (both use interface method definition) does not reflect the above meaning.

If our understanding of the problem domain is: Alarmdoor is inherently door in concept, it has the function of alerting. How do we design and implement to clearly reflect what we mean? As has been said before, abstract class represents an inheritance relationship in the Java language, whereas an inheritance relationship is essentially a "is-a" relationship. So for the concept of door, we should use the ABSTARCT class approach to define. In addition, Alarmdoor also has the function of alarm, which indicates that it can complete the behavior defined in the concept of alarm, so the concept of alarm can be defined by interface way. As shown below:

Copy Code code as follows:

Abstract class door{
abstract void open ();
abstract void close ();
}
Interface alarm{
void Alarm ();
}
Class Alarm Door extends Door implements alarm{
void Open () {...}
void Close () {...}
void alarm () {...}
}

This way of implementation can basically clearly reflect our understanding of the problem area and correctly reveal our design intent. In fact, abstract class is "is-a" relationship, Interface said is "like-a" relationship, we can as a basis for choice, of course, this is based on the understanding of the problem area, For example, if we think that Alarmdoor is essentially an alarm and has a door function, then the definition is reversed.

　　Summary

1.abstract class represents an inheritance relationship in the Java language, and a class can only use one inheritance relationship at a time. However, a class can implement multiple interface.

2. In abstract class, you can have your own data members, or you can have a ABSTARCT member method, whereas in interface you can have only static data members that cannot be modified (that is, it must be static final, but in Data members are not generally defined in interface, and all member methods are abstract.

3.abstract class and interface reflect the different design concepts. In fact, the abstract class represents the "is-a" relationship, interface represents the "like-a" relationship.

4. Classes that implement abstract classes and interfaces must implement all of these methods. Abstract classes can have non-abstract methods. There is no implementation method in the interface.

5. The variable defined in the interface defaults to the public static final type and must be given an initial value, so the implementation class cannot be redefined or changed.

6. Variables in an abstract class are friendly by default, and their values can be redefined in subclasses or assignable.

7. The methods in the interface are public,abstract types by default.

　　Conclusion

Abstract class and interface are two ways to define abstract classes in the Java language, and there is a great similarity between them. However, their choices often reflect the understanding of the conceptual nature of the problem area and the correctness and reasonableness of the reflection of the design intent, as they represent different relationships between concepts (although they can achieve the functional requirements). This is in fact a kind of idiomatic method of language, hope that the reader friend can understand carefully.