Subclasses should be specializations
m |
JaninaVoigt (Talk | contribs) |
||
| (One intermediate revision by one user not shown) | |||
| 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. In particular they say that ideally when using inheritance "anywhere the superclass is used, the subclass can be used" which is very similar to the [[Liskov substitution principle]]. |
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]] | ||
Latest revision as of 01:11, 20 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. In particular they say that ideally when using inheritance "anywhere the superclass is used, the subclass can be used" which is very similar to the Liskov substitution principle.
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.
