The top of the class hierarchy should be abstract
From CSSEMediaWiki
(Difference between revisions)
| Line 1: | Line 1: | ||
This idea is very tightly related to [[Riel's heuristics|Riel's heuristic]] ''[[Avoid concrete base classes]]''. It states that the class at the top of a class hierarchy should be abstract, and if it is not then there may be a design problem. If a subclass ''B'' overrides methods in its concrete superclass ''A'', it may indicate that there should be a common abstract superclass to ''A'' and ''B'' which defines common behaviour; then neither ''A'' or ''B'' need to redefine any methods. Any example of this is given in [[Avoid concrete base classes]]. | This idea is very tightly related to [[Riel's heuristics|Riel's heuristic]] ''[[Avoid concrete base classes]]''. It states that the class at the top of a class hierarchy should be abstract, and if it is not then there may be a design problem. If a subclass ''B'' overrides methods in its concrete superclass ''A'', it may indicate that there should be a common abstract superclass to ''A'' and ''B'' which defines common behaviour; then neither ''A'' or ''B'' need to redefine any methods. Any example of this is given in [[Avoid concrete base classes]]. | ||
| + | |||
| + | == See Also == | ||
| + | * [[Avoid concrete base classes]] | ||
[[Category: Johnson and Foote's heuristics]] | [[Category: Johnson and Foote's heuristics]] | ||
Revision as of 23:13, 1 September 2009
This idea is very tightly related to Riel's heuristic Avoid concrete base classes. It states that the class at the top of a class hierarchy should be abstract, and if it is not then there may be a design problem. If a subclass B overrides methods in its concrete superclass A, it may indicate that there should be a common abstract superclass to A and B which defines common behaviour; then neither A or B need to redefine any methods. Any example of this is given in Avoid concrete base classes.
