Category list

Chapter 4 The Relationships Between Classes and Objects

< Free Open Study >

Chapter 4 The Relationships Between Classes and Objects

Heuristic 4.1 Minimize the number of classes with which another class collaborates.

Heuristic 4.2 Minimize the number of message sends between a class and its collaborator.

Heuristic 4.3 Minimize the amount of collaboration between a class and its collaborator, that is, the number of different messages sent.

Heuristic 4.4 Minimize fanout in a class, that is, the product of the number of messages defined by the class and the messages they send.

Heuristic 4.5 If a class contains objects of another class, then the containing class should be sending messages to the contained objects, that is, the containment relationship should always imply a uses relationship.

Heuristic 4.6 Most of the methods defined on a class should be using most of the data members most of the time.

Heuristic 4.7 Classes should not contain more objects than a developer can fit in his or her short- term memory. A favorite value for this number is six.

Heuristic 4.8 Distribute system intelligence vertically down narrow and deep containment hierarchies.

Heuristic 4.9 When implementing semantic constraints, it is best to implement them in terms of the class definition. Often this will lead to a proliferation of classes, in which case the constraint must be implemented in the behavior of the class ”usually, but not necessarily , in the constructor.

Heuristic 4.10 When implementing semantic constraints in the constructor of a class, place the constraint test in the constructor as far down a containment hierarchy as the domain allows.

Heuristic 4.11 The semantic information on which a constraint is based is best placed in a central, third-party object when that information is volatile.

Heuristic 4.12 The semantic information on which a constraint is based is best decentralized among the classes involved in the constraint when that information is stable.

Heuristic 4.13 A class must know what it contains, but it should never know who contains it.

Heuristic 4.14 Objects that share lexical scope ”those contained in the same containing class ”should not have uses relationships between them.

< Free Open Study >

Chapter 5 The Inheritance Relationship

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 >