Avoid concrete base classes
| Line 9: | Line 9: | ||
[[Image:5.7 example1.png]] | [[Image:5.7 example1.png]] | ||
| − | + | ||
| + | This problem can be avoided by recognising that a NewEmployee and a FullEmployee have something in common, which can be represented by an abstract base class that they both inherit from. The new design would be: | ||
| + | |||
| + | [[Image:5.7 example2.png]] | ||
== See also == | == See also == | ||
Revision as of 00:37, 3 September 2008
Riel's heuristic #5.7: All base classes should be abstract classes.
What does Riel mean? Does he give an example? Have we got any examples of our own? Do we believe Riel?
Riel states that all base classes of an inheritance hierarchy should be abstract. Note that this does not mean that single classes with no inheritance hierarchy should be made abstract, as this would mean a concrete subclass would have to be created that adds no meaningful functionality - this violates Heuristic 3.7; Eliminate irrelevant classes.
This heuristic is a trade off between design complexity and flexibility. The example Riel gives (taken from the Object Oriented Design Heuristics book) is a FullEmployee class that inherits from a NewEmployee class. It seems to tie in with Avoid inheritance for implementation. In this case we cannot add something to the NewEmployee class without it also being added (via inheritance) to the FullEmployee class.
This problem can be avoided by recognising that a NewEmployee and a FullEmployee have something in common, which can be represented by an abstract base class that they both inherit from. The new design would be:
