1. Abstract mechanism of Object-Oriented Domain
Abstract mechanism is a necessary condition for Object-Oriented reusable design. The cornerstone of object-oriented reusable design is
Principle of opening/closingThat is, a software entity should be open to extensions and closed to modifications. The key to meeting the Open and closed principles lies in abstraction. In Java, one or more abstract classes or interfaces can be provided to specify all possible extensions. Therefore, all extensions will not change. This makes the abstract layer of the system not need to be modified, and thus satisfies the second article of the open and closed principle: Disable the modification. At the same time, because exporting one or more new classes from the abstraction layer can change the behavior of the system, the system is open to expansion. This satisfies the first article of the open/closed principle: open to expansion. All software systems share a common nature, that is, their requirements change over time. When the software system is facing new requirements, the system design must be stable. The design that meets the open/closed principle can bring certain adaptability and flexibility to the software system, and make the software system in change stable and continuous.
Abstract classes and interfacesIt is two methods of defining abstract classes in Java. They have great similarity. However, their choice often reflects the understanding of the concept nature in the problem field, and whether the reflection of design intent is correct and reasonable, because they represent the different relations between concepts. Only by correctly understanding the object-oriented design principles and using abstract classes and interfaces can an easy-to-use system be designed.
2.Differences between abstract classes and interfaces
(1) Differences in syntax
At the syntax layer, the Java language provides different definitions for abstract classes and interfaces. The following describes how to define an abstract class named demo. The demo abstract class is defined as follows: abstract class demo {abstract void Method1 (); abstract void method2 ();...} The demo interface is defined as follows: interface demo {void Method1 (); void method2 ();...} In the definition of abstract classes, demo can have its own data members or non-abstract member methods. In the definition of interfaces, demo can only have static final data members, all member methods are abstract. In a sense, an interface is a special form of abstract class. From the programming perspective, the inheritance rules of abstract classes and interfaces are different. abstraction only allows single inheritance, while a class can implement multiple interfaces. Interfaces support multiple inheritance. Secondly, in the definition of abstract classes, the default behavior of methods can be granted. In the definition of interfaces, methods cannot have default behaviors, the delegate must be used. In a sense, the interface is more abstract than the abstract class.
(2) differences at the design level
The above mainly discusses the differences between abstract classes and interfaces from the perspective of the syntax layer. The differences between these layers are relatively low-level and non-essential. This section analyzes and understands the essence of the two concepts from this design layer. Abstract classes reflect an inheritance relationship in the Java language. To make the inheritance relationship reasonable, there must be a "is-a" relationship between the parent class and the derived class, that is, the concept of parent class and Child class should be essentially the same. Otherwise, the interface does not require the implementer and interface definition to be consistent in concept, but only implement the interface definition contract. Consider this example. Suppose there is an abstract concept about the door, the door has two actions: open and close, in this case, we can define a type that represents the abstract concept through an abstract class or interface. The definition method of the door abstract class is as follows: abstract class door {abstract void open (); abstract void close ();} the door interface is defined as follows: interface door {void open (); void close ();} for other specific door types, you can use an abstract class to define the door or implements using the interface to define the door. It seems that there is no big difference between using abstract classes and interfaces. If you want the door to have the alarm function. The following describes possible solutions and analyzes them at the design layer. Solution 1: simply add an alarm method to the door 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 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 interface isolation principle. In the door definition, the behavior Methods inherent in the door concept are mixed with the behavior methods of another concept "alarm. One problem is that the modules that rely solely on the door concept will change with the concept of "alarm" (for example, modifying the parameters of the alarm method), and vice versa. Solution 2: Since open, close, and alarm belong to two different concepts, they should be defined in abstract classes that represent these two concepts according to the interface isolation principle. The two concepts are defined using abstract classes. Both concepts are defined using interfaces. One is defined using abstract classes, and the other is defined using interfaces. Obviously, because the Java language does not support multiple inheritance, it is not feasible to define both concepts using abstract classes. The latter two methods are feasible, but their selection reflects the understanding of the concept nature in the problem field, and whether the reflection of the design intent is correct and reasonable. If both concepts are defined using the interface method, there are two problems: first, we may not understand the problem field clearly. Is the concept of alarmdoor actually a door or an alarm? Second, if we have no problem with our understanding of the problem field, for example, through our analysis of the problem field, we find that alarmdoor is essentially consistent with door in concept, therefore, our design intent cannot be correctly revealed during implementation, because the definitions of these two concepts (both using interface-based definitions) do not reflect the above meaning. If our understanding of the problem field is: alarmdoor is essentially a door in concept, it also has the alarm function. How can we design and implement it to clearly reflect what we mean? As mentioned above, abstract classes represent an inheritance relationship in Java, and the inheritance relationship is essentially a "is-a" relationship. Therefore, we should use abstract classes to define the concept of door. In addition, alarmdoor has the alarm function, indicating that it can complete the behaviors defined in the alarm concept. Therefore, the alarm concept can be defined through interfaces. 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 implementation method can clearly reflect our understanding of the problem field and correctly reveal our design intent. In fact, the abstract class represents
"Is-"Link. Interface indicates"
Has-"Relationship can be used as a basis for selection. Of course, this is based on understanding the problem field. For example, if we think that alarmdoor is an alarm in concept, at the same time, it has the door function, so the above definition method will be reversed.