3.4 Another Example of Poor System Intelligence Distribution
Another example of system intelligence distribution can be drawn from the domain of a forced hot water, oil-
home heating system as described in Booch's book on object-oriented design . One portion of the requirement specification discusses the contents of each room in the house as consisting of a desired temperature input device, an actual temperature sensor, and an
sensor. A heat flow regulator is responsible for sensing when each room needs heat. If any of the rooms needs heat, the heat flow
turns on the
, waits for the water to heat up, and then
the room that heat is available. The method of determining if a room needs heat is to find the difference between the desired and actual
. If there is a person in the room, then heat should be provided as soon as the actual temperature is less than the desired temperature. If there is no person in the room, then the actual temperature is allowed to drop to five degrees less than the desired temperature before heat is supplied.
The first mistake that might be made is to create only the classes
sends messages to the other three classes in order to determine if the room needs heat (notice that the room class is conspicuously absent from the design in Figure 3.7). The
is a god class in this design. It
most of the work while the three classes with which it shares lexical scope perform relatively little work. This design
Heuristic 3.1 on distributing system intelligence horizontally.
Figure 3.7. Home heating system without encapsulation.
Due to the real-world domain of the home heating system, many designers immediately consider the room to be a reasonable class. Since each room object contains an object of each sensor, the room can encapsulate the three objects to facilitate the construction of more rooms. The typical error that occurs in this design is that the public interface of room is given operations such as
, etc. The
then asks the room for the actual temperature, the desired temperature, and whether or not someone is in the room. After collecting this information, the
computes whether or not a room requires heat.
The problem with this design is that the
is still a god class in that it performs most of the system's work, and the designer has failed to keep
data with its behavior. As stated earlier in this chapter, whenever a get or set function appears in an object-oriented design, it is important for the designer to ask, "What is it I'm doing with this data and why doesn't the class do it for me?"
The best solution to this particular problem is to let the room class decide when it needs heat (see Figure 3.8). It has all of the necessary data encapsulated within it, so it is the likely candidate for performing this calculation. Either the
asks each room if it requires heat (see Figure 3.9) or, as some designers prefer, the room objects demand heat from the
. We will later see that logical design does not care one way or the other. Physical design, for example, choice of software/hardware platform or efficiency, will most likely
one message direction over the other.
Figure 3.8. Home heating system with encapsulation.
Figure 3.9. Home heating system with distributed intelligence.
A last tongue-in-cheek heuristic for finding god classes in your system is to write down all of the classes on a sheet of paper. Ask each developer which
1 of the
classes he or she would be willing to write. If everyone avoids one class, then that is the god class you are looking for. For example, of the five classes in the first design of the home heating system, everyone will avoid the
since it is the most complicated. It is important to note that a workaholic in your
will spoil the results of this test.
Model the real world whenever possible. (This heuristic is often violated for reasons of system intelligence distribution,
of god classes, and the keeping of related data and behavior in one place.)
Heuristic 3.6 is motivated by the
for a maintenance person (i.e., the author of the software three months later when he or she cannot remember what they did or why!) to be able to directly relate to the architecture of the system. When the home heating system problem is used in a design course as an exercise, many groups have a heated discussion concerning the room. Some members of the groups argue that rooms do not do anything in the real world and, therefore, should not be a class. Other
argue that a room class is necessary for encapsulation and intelligence distribution. I tend to side with the latter. The modeling of the real world is desirable, but not nearly as important as the other heuristics. Some designers
this problem by renaming the room class to something more
, such as roomcontroller,
, or roommechanism. In a design critique it is important that individuals realize when they are arguing about some interesting and important design decision and when they are only arguing about the name of a class. I do not mind arguing six hours over the
of a class so long as I understand that is the sole ramification of the argument. Many hours of design critique are
by confusion between design issues and other matters such as class