Previous Section  < Free Open Study >  Next Section

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-fired home heating system as described in Booch's book on object-oriented design [7]. 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 occupancy sensor. A heat flow regulator is responsible for sensing when each room needs heat. If any of the rooms needs heat, the heat flow regulator turns on the furnace, waits for the water to heat up, and then tells 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 temperatures. 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 HeatFlow-Regulator, DesiredTempDev, ActualTempDev, and OccupancySensor. The HeatFlowRegulator 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 HeatFlowRegulator is a god class in this design. It performs most of the work while the three classes with which it shares lexical scope perform relatively little work. This design violates Heuristic 3.1 on distributing system intelligence horizontally.

Figure 3.7. Home heating system without encapsulation.

graphics/03fig07.gif

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 get_actual_temp(), get_desired_temp(), is_occupied(), set_desired_temp(), etc. The HeatFlowRegulator 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 HeatFlowRegulator computes whether or not a room requires heat.

The problem with this design is that the HeatFlowRegulator is still a god class in that it performs most of the system's work, and the designer has failed to keep related 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 HeatFlowRegulator asks each room if it requires heat (see Figure 3.9) or, as some designers prefer, the room objects demand heat from the HeatFlowRegulator. 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 dictate one message direction over the other.

Figure 3.8. Home heating system with encapsulation.

graphics/03fig08.gif

Figure 3.9. Home heating system with distributed intelligence.

graphics/03fig09.gif

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 n - 1 of the n 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 HeatFlowRegulator since it is the most complicated. It is important to note that a workaholic in your group will spoil the results of this test.

Heuristic 3.6

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.)

Heuristic 3.6 is motivated by the desire 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 members 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 reconcile this problem by renaming the room class to something more benign, such as roomcontroller, thermostat, 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 name of a class so long as I understand that is the sole ramification of the argument. Many hours of design critique are wasted by confusion between design issues and other matters such as class names.

    Previous Section  < Free Open Study >  Next Section