|
|
|
|
|
|
|
As you solve these problems, you will begin to design your classes. For example, you already have an indication that HeatSensor will derive from Sensor. If the sensor is to make periodic reports, it may also derive via multiple inheritance from Timer, or it may have a timer as a member variable. |
|
|
|
|
|
|
|
|
The HeatSensor will probably have member functions, such as CurrentTemp() and SetTempLimit(), and will probably inherit functions such as SoundAlarm() from its base class, Sensor. |
|
|
|
|
|
|
|
|
A frequent issue in object-oriented design is that of encapsulation. You could imagine a design in which the alarm system has a setting for MaxTemp. The alarm system asks the heat sensor what the current temperature is, compares it to the maximum temperature, and sounds the alarm if it is too hot. One could argue that this violates the principle of encapsulation. Perhaps it would be better if the alarm system didn't know or care about the details of temperature analysisarguably that should be in the HeatSensor. |
|
|
|
|
|
|
|
|
Whether or not you agree with that argument, it is the kind of decision you want to focus on during the analysis of the problem. To continue this analysis, one could argue that only the sensor and the Log object should know any details of how sensor activity is logged; the Alarm object shouldn't know or care. |
|
|
|
|
|
|
|
|
Good encapsulation is marked by each class having a coherent and complete set of responsibilities, and no other class having the same responsibilities. If the Sensor is responsible for noting the current temperature, no other class should have that responsibility. |
|
|
|
|
|
|
|
|
On the other hand, other classes might help deliver the necessary functionality. For example, while it might be the responsibility of the Sensor class to note and log the current temperature, it might implement that responsibility by delegating to a Log object the job of actually recording the data. |
|
|
|
|
|
|
|
|
Maintaining a firm division of responsibilities makes your program easier to extend and maintain. When you decide to change the alarm system for an enhanced module, its interface to the log and to the sensors will be narrow and well defined. Changes to the alarm system should not affect the Sensor classes, and vice versa. |
|
|
|
|
|
|
|
|
Should the HeatSensor have a ReportAlarm() function? All sensors will need the ability to report an alarm. This is a good indication that ReportAlarm() should be a virtual method of Sensor, and that Sensor may be an abstract base class. It is possible that HeatSensor will chain up to Sensor's more general ReportAlarm() method; the overridden function would just fill in the details it is uniquely qualified to supply. |
|
|
|
|
|