Action Oriented vs Object Oriented

• Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly.
• Do not create god classes/objects in your system. Be very suspicious of a class whose name contains Driver, Manager, System, or Subsystem.
• 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 noncommunicating behavior, that is, methods that operate on a proper subset of the data members of a class. God classes often exhibit a great deal of noncommunicating behavior.
• In applications that consist of an object-oriented model interacting with a user interface, the model should never be dependent on the interface. The interface should be dependent on the model.
• Model the real world whenever possible. (This heuristic is often violated for reasons of system intelligence distribution, avoidance of god classes, and the keeping of related data and behavior in one place.)
• Eliminate irrelevant classes from your design. Heuristic 3.8 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 or is derived from a verb, especially those that 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.
• 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.