SDSU CS 535: Object-Oriented Programming & Design
Fall Semester, 1997
Doc 26, Some Heuristics

To Lecture Notes Index
San Diego State University -- This page last updated 03-Dec-97

Contents of Doc 26, Some Heuristics

  1. Meyer's Criteria for Evaluating for Modularity
  2. Basic Heuristics
  3. Relationships between Objects
  4. Heuristics for the Uses Relationship
  5. Containment Relationship
    1. Semantic Constraints Between Classes
    2. More Containment Heuristics

Object-Oriented Design Heuristics, Riel, 1996

Various sections in chapters 2-4 as indicated by the listed heuristics

Doc 26, Some Heuristics Slide # 1

Meyer's Criteria for Evaluating for Modularity






Doc 26, Some Heuristics Slide # 2

Basic Heuristics

2.1 All data should be hidden within its class

2.8 A class should capture one and only one key abstraction

2.9 Keep related data and behavior in one place

3.1 Distribute system intelligence horizontally as uniformly as possible

3.2 Do not create god classes in your system

3.3 Beware of classes that have many accessor (get-set) methods defined in their public interface. Having many implies that the related data and behavior are not being kept in one place

3.4 Beware of classes with too much noncommunicating behavior

2.11 Be sure the abstractions that you model are classes and not simply the roles objects play

3.9 Do not turn an operation into a class

Doc 26, Some Heuristics Slide # 3

Relationships between Objects

Type of Relations:

Object A uses object B if A sends a message to B
Usually assume that A and B objects of different classes
A is the sender, B is the receiver

Class A contains class B when A has a field of type B
That is an object of type A will have an object of type B inside it

Doc 26, Some Heuristics Slide # 4
Six different Ways to implement Uses

How does the sender access the receiver ?

1. Containment
The receiver is a field in the sender
class Sender
   Receiver here;
   public void method()

2. Argument of a method
The receiver is an argument in one of the senders methods
class Sender
   public void method(Receiver here)

Doc 26, Some Heuristics Slide # 5

3. Ask someone else
The sender asks someone else to give them the receiver
How does receiver access the someone else?
class Sender
   public void method()
      Receiver here = someoneElse.getReceiver();

4. Global
The receiver is global to the sender

5. Creation
The receiver is created by the sender
class Sender
   public void method()
      Receiver here = new Receiver();

6 Referential Attribute (Other)

Doc 26, Some Heuristics Slide # 6

Heuristics for the Uses Relationship

4.1 Minimize the number of classes with another class collaborates

Doc 26, Some Heuristics Slide # 7

Containment Relationship

4.5 If class A contains objects of class B, then A should be sending messages to it's fields of type B.

The one exception to 4.5 are container classes

4.5 prohibits the following behavior in a non-container class
class Foo
   Bar data;

   public Bar getData() 
      return data;

   public void setData( Bar newData)
      data = newData;

4.6 Most of the methods defined on a class should be using most of the fields in the class most of the time

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

Doc 26, Some Heuristics Slide # 8
Narrow and Deep Containment Hierarchies

Combining fields into new classes can reduce the number of fields in a class
A broad and shallow Containment Hierarchy
A narrow and deep Containment Hierarchy

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

Doc 26, Some Heuristics Slide # 9

Semantic Constraints Between Classes

Examples of semantic constraint:
A meal should start with appetizer, then the entree, then dessert
A meal will have two vegetables out of a choice of peas, corn, squash, and asparagus, but peas and corn are not allowed in the same meal

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.

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 a the domain allows.

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.

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.

Doc 26, Some Heuristics Slide # 10

More Containment Heuristics

4.14 Objects that are contained in the same containing class should not have a uses relationships between them.

Contained Objects with uses relationships

The containing class should send messages to the contained objects

Doc 26, Some Heuristics Slide # 11

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

If a number of classes depend on each other in a complex way, you can violate 4.13 to reduce the number of classes they interact with.

Wrap the classes in a containing class.

Each contained class sends a message to the containing class, which broadcasts the message to the proper contained objects
Complex interactions
Replacing complex interaction with containing class

visitors since 03-Dec-97