SDSU CS 535 Object-Oriented Programming & Design
Spring Semester, 1999
Inheritance Heuristics
Previous    Lecture Notes Index    Next    
© 1999, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 22-Apr-99

Contents of Doc 17, Inheritance Heuristics


Reference

Object-Oriented Design Heuristics , Riel, Addison-Wesley, 1996,

Doc 17, Inheritance Heuristics Slide # 2

Inheritance Relationships


5.2 Derived classes must have knowledge of their base classes by definition, but base classes should not know anything about their derived classes.

5.3 All data in a base class should be private; do not use protected data.

5.4 In theory, inheritance hierarchies should be deep – the deeper the better

5.5 In practice, inheritance hierarchies should be no deeper than about 6 levels.

5.6 All abstract classes must be base classes.

5.7 All base classes should be abstract classes.

5.8 Factor the commonality of data, behavior, and/or interface as high as possible in the inheritance hierarchy.

5.9 If two or more classes share only common data (no common behavior), then that common data should be placed in a class that will be contained by each sharing class.

5.10 If two or more classes share common data and behavior, then those classes should inherit from a common base class that captures those data and methods.

5.11 If two or more classes share only a common interface (messages not methods), then they should inherit from a common base class only if they will be used polymorphically.

5.12 Explicit case analysis on the type of an object is usually an error. Polymorphism should be used in most of these cases.

5.15 Do not turn objects of a class into derived classes of the class. Be very suspicious of any derived class for which there is only one instance.

Copyright ©, All rights reserved.
1999 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
OpenContent license defines the copyright on this document.

Previous    visitors since 22-Apr-99    Next