A place to list and discuss rules of thumb relating to object topology.
See: Riel, A (1996), Object Oriented Design Heuristics, ISBN 020163385X.
- Distribute system intelligence horizontally as uniformly as possible -- Avoid GodClasses.
- Do not create god classes / objects in your system. Beware of a class whose name contains DRIVER, MANAGER, SYSTEM, or SUBSYSTEM.
For both the above points, GodClasses have, by definition, a lot of built-in behavior. This in turn leads to collaboration classes with little or no built-in behavior, often just data members. Given that behavior classes are difficult to quasi-impossible to reuse, and that 'dumb' behavior-less classes can also be difficult to reuse, the trick is to find the right balance of data and behavior. Given a class-design continuum like this:
The art of class design is finding the right balance point for classes (and hence the flavor of the whole system), and this heuristic says the right balance point is probably not near either extreme end.
- Beware of classes that have many accessor methods defined in their public interface. Having many implies that related data and behavior are not being kept in one place.
- Beware of classes that have too much non-communicating behavior.
- In an application that consists of an object-oriented model interacting with a user interface, the model should never be dependent on the interface.
- Model the real world whenever possible.
- Eliminate irrelevant classes from your design.
- Eliminate classes that are outside the system.
- Do not turn an operation into a class. Be suspicious of any class whose name is a verb.
- Agent classes are often placed in the analysis model of an application. Try to remove them.
Category OOPrinciples, other Object Oriented Heuristics
( Topic last updated: 1999.08.25 12:20:01 PM )