Top 20 Design Heuristics

from Arthur Riel's 61 Object Oriented Design Heuristics

This document lists a subset of the 61 heuristics from Arthur Riel's book Object-Oriented Design Heuristics (Addison-Wesley, 1996).  The accompanying text gives some interpretation of the meaning of the heuristics.

What are design heuristics?

The OO Design Heuristics are a set of guidelines for good object oriented designs. As Bjarne Stroustrup (inventor of the C++ programming language) pointed out many years ago, just making a design "object oriented" doesn't always mean that you are making the design "good". In fact, many inexperienced designers have a very weak understanding of object oriented design -- and there are a number of common design mistakes that they make.

Here is one example:

How should I use the heuristics?

The design heuristics are a good "checklist for designers":

The heuristics should never be taken as "absolute rules" -- and in fact, some of the heuristics are contradictory. The heuristics are useful for evaluating the goodness of a design.

Heuristic 2.2: Users of a class must be dependent on its public interface, but a class should not be dependent on its users.

Heuristic 2.6: Do not clutter the public interface of a class with things that users of that class are not able to use or are not interested in using. Heuristic 2.8: A class should capture one and only one key abstraction. Heuristic 3.2: Do not create god classes/objects in your system.  Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem. Heuristic 3.3: Beware of classes that have many accessor methods defined in their public interface, many of them imply that related data and behavior are not being kept in one place. Heuristic 3.4: Beware of classes which have too much non-communicating behavior, i.e. methods which operate on a proper subset of the data members of a class.  God classes often exhibit lots of non-communicating behavior. Heuristic 3.9: Do not turn an operation into a class.  Be suspicious of any class whose name is a verb or derived from a verb.  Especially those which have only one piece of meaningful behavior (i.e. do not count sets, gets, and prints).  Ask if that piece of meaningful behavior needs to be migrated to some existing or undiscovered class. Heuristic 3.10: Agent classes are often placed in the analysis model of an application.  During design time, many agents are found to be irrelevant and should be removed. Heuristic 4.8: Distribute system intelligence vertically down narrow and deep containment hierarchies. 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 5.1: Inheritance should only be used to model a specialization hierarchy. 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 only share common data (no common behavior) then that common data should be placed in a class which 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 which captures those data and methods. Heuristic 5.11: If two or more classes only share 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.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.17: It should be illegal for a derived class to override a base class method with a NOP method, i.e. a method which does nothing.

Last modified: Mar. 18, 2015