Subclasses should be specializations
m |
|||
| Line 1: | Line 1: | ||
| − | Johnson and Foote defined that | + | Johnson and Foote defined that subclasses should be considered as a specialized entity of the superclass. Hence subclasses should not redefine any of the methods already defined in the superclass. Subclasses should only add new methods. |
However, the authors also recognized that there may be some exceptions to the rule defined above. One example is the case of an abstract superclass. In such a case, subclasses must implement all methods declared in the abstract superclass. Secondly, they suggest there may be some cases where a subclass may not be a specialization of the super class. For example, a subclass may be used to wrap the super class, possibly to encapsulate legacy code. In this case, the subclass may be more general than its superclass, or may have very little relationship with the super class. This would appear to be [[Inheritance for implementation]], where inheritance is being used purely for the purpose of code reuse. A further reorganization of the class hierarchy is necessary if we fall into this kind of situation. | However, the authors also recognized that there may be some exceptions to the rule defined above. One example is the case of an abstract superclass. In such a case, subclasses must implement all methods declared in the abstract superclass. Secondly, they suggest there may be some cases where a subclass may not be a specialization of the super class. For example, a subclass may be used to wrap the super class, possibly to encapsulate legacy code. In this case, the subclass may be more general than its superclass, or may have very little relationship with the super class. This would appear to be [[Inheritance for implementation]], where inheritance is being used purely for the purpose of code reuse. A further reorganization of the class hierarchy is necessary if we fall into this kind of situation. | ||
| Line 10: | Line 10: | ||
* [[Liskov substitution principle]] | * [[Liskov substitution principle]] | ||
* [[Design by contract]] | * [[Design by contract]] | ||
| + | |||
| + | [[Category: Johnson and Foote's heuristics]] | ||
Revision as of 01:20, 18 August 2009
Johnson and Foote defined that subclasses should be considered as a specialized entity of the superclass. Hence subclasses should not redefine any of the methods already defined in the superclass. Subclasses should only add new methods.
However, the authors also recognized that there may be some exceptions to the rule defined above. One example is the case of an abstract superclass. In such a case, subclasses must implement all methods declared in the abstract superclass. Secondly, they suggest there may be some cases where a subclass may not be a specialization of the super class. For example, a subclass may be used to wrap the super class, possibly to encapsulate legacy code. In this case, the subclass may be more general than its superclass, or may have very little relationship with the super class. This would appear to be Inheritance for implementation, where inheritance is being used purely for the purpose of code reuse. A further reorganization of the class hierarchy is necessary if we fall into this kind of situation.
Riel's heuristic Inheritance for specialization is derived from this idea.
