|
|
|
|
|
|
|
When your sensors report an alarm condition, they will want to provide a lot of information to the object that phones the police and to the log. It may well be that you'll want to create a Condition Class, whose constructor takes a number of measurements. Depending on the complexity of the measurements, these too might be objects, or they might be simple scalar values such as integers. |
|
|
|
|
|
|
|
|
It is possible that Condition objects are passed to the central alarm object; or that Condition objects are subclassed into Alarm objects, which themselves know how to take emergency action. Perhaps there is no central object; instead, there might be sensors that know how to create Condition objects. Some Condition objects would know how to log themselves; others might know how to contact the police. |
|
|
|
|
|
|
|
|
A well-designed, event-driven system need not have a central coordinator. One can imagine the sensors all independently receiving and sending message objects to one another, setting parameters, taking readings, monitoring the house. When a fault is detected, an Alarm object is created, which logs the problem (by sending a message to the Log object?) and takes the appropriate action. |
|
|
|
|
|
|
|
|
To simulate such an event-driven system, your program needs to create an event loop. An event loop is typically an infinite loop such as while(1) that gets messages from the operating system (mouse clicks, keyboard presses, and so on) and dispatches them one by one, returning to the loop until an exit condition is satisfied. Listing 22.1 shows a rudimentary event loop. |
|
|
|
|
|
|
|
|
LISTING 22.1 A SIMPLE EVENT LOOP |
|
|
|
 |
|
|
|
|
1: // Listing 22.1
2:
3: #include <iostream.h>
4:
5: class Condition
6: {
7: public:
8: Condition() { }
9: virtual ~Condition() {}
10: virtual void Log() = 0;
11: };
12:
13: class Normal : public Condition
14: {
15: public: |
|
|
|
|
|
|
|
|
continues |
|
|
|
|
|