Other specific DOOR types can use the Door or Implements defined using the Abstract Class method using the interface 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. Other aspects have been simplified or ignored) Possible solutions and analysis from these different schemes from the design concept layer.
Solution 1:
Simply add an ALARM method in Door's 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 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 Principle) in object-oriented design, and mixing the behavior method inherent in the DOOR concept itself and another concept "alarm" behavior method is mixed together. 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. The definition method is: These two concepts use the Abstract Class method definition; both concepts use the interface mode definition; one concept uses the Abstract Class method definition, and the other concept is defined using the interface. Obviously, since the Java language does not support multiple inheritance, two concepts are not feasible to use the Abstract Class method. The following two methods are feasible, but for their choice but reflect the understanding of the concept of the concept in the field, it is correct and reasonable for the design intent. Let us analyze and explain. If the two concepts use the interface method to define, then two questions: 1. We may not understand the problem area, Alarmdoor is in the concept of Door or alarm? 2, if we have no problem in the understanding of the problem, for example, we have found that Alarmdoor is consistent with the concept of the problem, so we have no correctness in the concept, because we are implementing our design intention. In definitions of these two concepts (all defined using the Interface mode) reflects the above meanings. If we understand the problem of the problem is: AlarmDoor is in nature in nature, and it has a function of alarm. How should we design and implement it to clearly reflect our mean? As mentioned earlier, Abstract Class represents a inheritance relationship in the Java language, and inheritance relationship is essentially "IS A" relationship. So for the concept of Door, we should use the AbStarct Class to define. In addition, AlarmDoor has an alarm function indicating that it can complete the behavior defined in the alarm concept, so the alarm concept can be defined by the interface. As shown below: Abstract Class Door {
Abstract void open ();
Abstract void close ();
}
Interface alarm {
Void alarm ();
}
Class alarmdoor extends door imports alarm {
Void open () {...}
void close () {...}
Void alarm () {...}
}
