Summary of Heuristics

 <  Free Open Study  >  

Heuristic 5.1 Inheritance should be used only to model a specialization hierarchy.

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

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

Heuristic 5.4 In theory, inheritance hierarchies should be deep ”the deeper, the better.

Heuristic 5.5 In practice, inheritance hierarchies should be no deeper than an average person can keep in his or her short- term memory. A popular value for this depth is six.

Heuristic 5.6 All abstract classes must be base classes.

Heuristic 5.7 All base classes should be abstract classes.

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

Heuristic 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.

Heuristic 5.10 If two or more classes have common data and behavior (i.e., methods), then those classes should each inherit from a common base class that captures those data and methods .

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

Heuristic 5.12 Explicit case analysis on the type of an object is usually an error. The designer should use polymorphism in most of these cases.

Heuristic 5.13 Explicit case analysis on the value of an attribute is often an error. The class should be decomposed into an inheritance hierarchy, where each value of the attribute is transformed into a derived class.

Heuristic 5.14 Do not model the dynamic semantics of a class through the use of the inheritance relationship. An attempt to model dynamic semantics with a static semantic relationship will lead to a toggling of types at runtime.

Heuristic 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.

Heuristic 5.16 If you think you need to create new classes at runtime, take a step back and realize that what you are trying to create are objects. Now generalize these objects into a class.

Heuristic 5.17 It should be illegal for a derived class to override a base class method with a NOP method, that is, a method that does nothing.

Heuristic 5.18 Do not confuse optional containment with the need for inheritance. Modeling optional containment with inheritance will lead to a proliferation of classes.

Heuristic 5.19 When building an inheritance hierarchy, try to construct reusable frameworks rather than reusable components .

 <  Free Open Study  >  


Object-Oriented Design Heuristics
Object-Oriented Design Heuristics (paperback)
ISBN: 0321774965
EAN: 2147483647
Year: 1996
Pages: 180

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net