Broadcasters and receivers in many forms are common in event-driven programs. A broadcaster is an object that randomly broadcasts messages to unknown numbers and types of receivers. Receivers are objects that are either always on-perpetually listening or polling for broadcasts-or usually off-expecting to be awakened when a broadcast occurs. Pirate radio stations, local area networks, and underground magazine publishers are examples of broadcasters, while radios, networked computers, and magazine subscribers are examples of receivers. The mouse and keyboard of a computer can also be regarded as broadcasters, while mouse and keyboard handlers can be regarded as receivers. Because broadcast messages are un-addressed and occur randomly, they are often called events. In this case receivers are called event handlers, broadcasters are called event sources, and broadcasting is called event firing.

To avoid polling, which consumes too much time and bandwidth, many platforms provide several types of event notification mechanisms. These mechanisms can be viewed as instances of various event notification design patterns. The Publisher-Subscriber pattern is a simple and prevalent example of such a pattern. As such, it provides an excellent introduction to design patterns.

After a few background remarks on design patterns, a model of a fictional power plant is described. Various power plant sensors need to be notified when the reactor gets too hot. The Publisher-Subscriber pattern is presented as a solution to the problem. Of course event notification is important at higher levels of abstraction, too. To demonstrate this point a programmable constraint network is designed and built. (Constraint networks are closely related to spread sheets, which are explored in the problem section.) The role of event notification in general and of the Publisher-Subscriber pattern in particular will be revisited by the pipeline toolkit in Chapter ? and by the application frameworks in Chapter ?.

The design principles discussed in the previous chapter are merely ways to measure the quality of a given design. They don't really tell us how to create good designs. In fact, creating a design from scratch is difficult. How should we begin? Where should we begin? How can we guard against needing to redesign? How will we answer critics who ask why we chose one design and not another? What we really need are reusable designs.

Surprisingly, reusable designs exist. The idea comes from architecture, where a group of architects and city planners calling themselves New Urbanists are asking why armies of professionally trained architects and engineers equipped with modern methods and technology produce strip malls, tract homes, parking lots, and golden arches? What happened to the charming main streets, parks, cafes, churches, hotels, gardens, and homes built by our untrained, ill-equipped predecessors?

To be sure, much of the answer involves economics and politics, but in his book The Timeless Way of Building [ALX] Christopher Alexander argues that we have lost our sense of design. Having delegated the job to experts, methodologies, and regulations, we have forgotten how to build.

How do we regain this sense? Unfortunately, good design can't be explicitly defined. It is too deeply rooted in human experience to be isolated in a neat phrase. It is part of our background "knowledge," and as such, it can't be completely pulled into the foreground. (See [WIN] for more detail on this idea.) Words like living, organic, authentic, and self sustaining are close synonyms, but they fall short. In the end, Alexander calls it the quality without a name. Calling designs "patterns", he writes:

This resonates somewhat with programming, too. A good design is almost instantly recognized by an experienced programmer. It sparks a feeling of delight and satisfaction that transcends our goals and principles. This is not to say that good design is subjective or unrecognizable. Recognizing good design is like recognizing good wine. While not everyone can taste the difference between sour grape juice and a complex cabernet at first, we can train ourselves to become connoisseurs. In the case of wine, this is a matter of tasting lots of examples of good wine, learning to distinguish subtle features, and learning to communicate with other wine experts. Alexander proposes a similar idea for architects: pattern catalogs.

A design pattern is a recurring design problem together with a generic, reusable solution. A pattern catalog collects, classifies, and names design patterns mined from well designed structures. The patterns in a catalog usually follow Alexander's problem-solution format:

While the impact of pattern catalogs on architecture remains to be seen, they have had a big impact on object oriented software engineering. Inspired by Alexander's ideas, small groups of programmers have been assiduously mining and cataloging software design patterns. Several well known catalogs exist ([Go4], [POSA]), there are pattern groups (Hillside, Siemens), pattern conferences (PloP and EuroPloP), pattern web sites ([WWW 8], [WWW 9]), there is even a catalog of anti patterns [ANTI]. Pattern catalogs are now an important weapon in a programmer's arsenal of tricks and tools.

Assume we are in the early design phase of a project to provide software that will control and monitor a nuclear reactor. Here's a description of the application domain:

Here's our initial model of the domain:

Our prototype initially represents reactors, sensors, and consoles as objects within the same program that communicate by invoking methods.

It's too soon to specify the details of sensors and consoles, we can at least assume that each of these devices maintains a reference to the reactor it monitors:

How will the reactor notify sensors of changes in its temperature? The sensors could continually poll the reactor:

This might be possible in the final deployment where the control loop of each sensor runs on a dedicated processor, although it will generate an unacceptable level of network traffic. After all, changes in the temperature of the reactor's core will probably be relatively infrequent compared to the polling frequency. In our prototype the reactor, console, and sensors all run in the same thread of control, so polling isn't an option.

We could add a sequence of statements to Reactor.inc() and Reactor.dec() that call specific methods of each sensor:

The problem with this solution is that each time a new sensor is added to the system, we will have to add statements to inc() and dec(). This is an example of tight coupling. It creates dependencies between the reactor and the sensors, and it is exactly what the last sentence in the domain description asks us not to do. Why? The program that actually controls the reactor is probably complicated, very specialized, and, more importantly, it must never fail! Each time we allow people to modify this program when a new type of sensor is added to the system, we open the door for introducing bugs (and melt downs).

It's time to reach for a pattern catalog. The Publisher-Subscriber pattern is listed in several:

An entry in a pattern catalog often includes a discussion of advantages and disadvantages of the pattern as well as actual examples of usage.

Pattern catalog entries often include a class diagram:

Subscriber is an abstract class because update() is a pure virtual function that will be implemented differently in different derived classes. Alternatively, we could have stereotyped Subscriber as an interface.

Entries may also include sequence diagrams. Assume two monitors subscribe to a device. When the device changes state, monitor1.f() and monitor2.g() must be called:

Pattern catalog entries don't usually include implementations, because they are meant to be language independent. It is the programmer's job to provide the implementation. Some patterns are so useful, they are provided in well known libraries. For example, specializations of publisher and subscriber classes are also provided in the Microsoft Foundation Class library, where they are called CDocument and CView and IBM's Visual Age library, where they are called Notifier and Subscriber. Publisher and subscriber classes are provided in the Java utility package, where they are called Observable and Observer.

Observers are subscribers:

Observables are publishers:

Returning to our power plant example, here is a screen shot of the reactor's console window:

The window contains an "inc" button that increments the temperature of the reactor by 500 degrees and a "dec" button that decrements the reactor's temperature by 50 degrees. In the middle, a thermometer displays the reactor's temperature. When the reactor's temperature exceeds 1500 degrees, several beeps can be heard and the message:

appears several times in the DOS/Unix console window. These actions are the result of beeping and printing alarms that monitor the reactor's temperature.

The reactor class is almost the same as before, except it now extends Java's Observable class. The "setter" methods (i.e., those methods that modify the reactor's state) end with the sequence:

Of course notifyObservers() calls all registered observers.

There are two types of subscribers: dedicated and non-dedicated. An non-dedicated subscriber can be updated by multiple publishers, while a dedicated subscriber assumes it is always updated by a particular publisher.

In our power plant prototype sensors are subscribers. We introduce three types of sensors: thermometers, printing alarms, and beeping alarms. For demonstration purposes, alarms are non-dedicated, while thermometers are dedicated.

The update() function of an non-dedicated subscriber must explicitly downcast its publisher reference parameter before it can use it. For safety, we will perform a safe cast (i.e., ask if the publisher is an instance of the Reactor class).

A thermometer is a label and an observer. An instance variable references the reactor the thermometer observes. One advantage of this approach is that the thermometer constructor can perform the subscription operation on behalf of the client:

The reactor console is a closeable frame (MainJFrame, see Programming note 3.1).

The reactor constructor creates two printing alarms and two beeping alarms. All four alarms are added to the reactor's observer list:

Next, panels holding the buttons and thermometer are created. Note that the thermometer doesn't have to be added to the reactor's observer list because the thermometer's constructor does this automatically:

Finally, the panels are added to the JFrame's content pane:

JFC is a "framework" for building graphical user interfaces. These include the classes in the java.awt and javax.swing packages, Java Accessibility, Java 2D, Java 3D, etc. A JFC GUI is a window containing GUI components such as buttons, menus, text fields, etc.. Here are a few of the JFC component classes:

Most GUI components fire events when manipulated by users. Here are a few JFC event classes:

For example, the reactor console indirectly extends JFrame and contains two JButtons and a JLabel:

When the user presses either the "inc" or "dec" button, an action event is fired and the corresponding reactor method is invoked. But how does the console know when an action event has been fired?

In JDK 1.0 every action event was routed to the other GUI components. Each component could either handle the event or ignore it. This scheme was inefficient because a lot of time was wasted routing the event to disinterested components.

In later versions of Java a strategy called event delegation was adopted. Under this scheme programmers were required to register listener objects with each component that fired events the programmer wanted to handle. When a component fires an event, the event is only routed to registered listeners. If there are no registered listeners-- if the programmer isn't interested in a particular event-- then no routing occurs. all listeners must realize one or more listener interfaces:

For example, in the reactor console constructor, an IncAction listener is added to the list of listeners for the "inc" button and a DecAction listener is added to the list of listeners for the "dec" button (these are the only listeners):

IncAction and DecAction are declared as inner classes of the ReactorConsole class. This is commonly done because these classes are seldom reusable outside of a particular GUI, but also because inner class instances have access to the private variables of the outer class instance that creates them. Thus, our listeners can access the myReactor reference of the reactor console that creates them:

Notice that this is yet another example of the Publisher-Subscriber pattern. Components are publishers. They publish events. Listeners are subscribers. They must implement methods prescribed by appropriate listener interfaces and they must register with the components they listen to. When an event is fired, the appropriate methods of every registered listener is called.

A constraint network represents a mathematical relationship between several variables, and is able to compute the value of any one of these variables given the values of all the others.

There are two types of nodes in a constraint network: cells and constraints. Cells represent variables (read-only cells represent constants) and constraints represent primitive mathematical relationships such as z = x + y and z = x * y. The neighbors of a constraint are the cells that it constrains. The neighbors of a cell are the constraints that constrain it.

A number can be saved to or erased from a cell. In either case, the cell's neighboring constraints will be notified. Upon notification that a neighboring cell has been erased, a constraint erases all of its neighbors. Upon notification that a number has been stored in a neighboring cell, a constraint attempts to compute new values for its remaining neighbors. In either case, cells updated by a constraint notify the other constraints they are connected to. In this way cell updates cascade through the network.

For example, assume x, y, and z are cells connected to an addition constraint. If a number is stored in x, and if y already holds a number, then the adder constraint stores x + y in z. However, if y doesn't hold a value, but z does, then the adder constraint stores z - x in y. Contrast this "bi-directional" behavior with the "uni-directional" behavior of the ordinary assignment statement:

which only assigns x + y to z.

As a more complex example, consider the relationship:

We can represent this as a constraint network consisting of three constraints and seven cells:

In this network the cells labeled 3 and 4 are constant or read-only cells. The cells labeled 3x and 4y hold 3 * x and 4 * y. The nodes labeled + and * are constraints.

Assume x = 2 and y is undefined. In this case 3x = 6 and 4y is undefined. Assume 26 is stored in z. The adder constraint stores 26 - 6 = 20 in 4y. At this point the right multiplier constraint stores 20/4 = 5 in y.

Our constraint network is called ConNet. The implementation is based on [AbS]. ConNet's console executes the following commands:

Let's program ConNet to solve the equation:

We begin by creating three cells representing the variables x, y, and z:

Next, we create two cells that hold the constants 3 and 4, as well as two cells to hold the intermediate values of 3x and 4y:

We create three constraints. The first asserts that 4y holds the product of 4 and y, the second asserts that 3x holds the product of 3 and x, and the third asserts that z holds the sum of 3x and 4y:

Normally, cells are updated quietly. If we want a cell to display itself when it is updated, we must explicitly ask it to do so. In our example, we are only interested in the values held by x, y, and z:

Suppose we want to compute y assuming x = 3.14 and z = 9. In this case

To do this, we simply set x to 3.14 and z to 9:

Next, let's compute z assuming x = 5 and y = 3. In this case:

We begin by erasing the current values held by x, y, z, 3x, and 4y:

Of course only x, y, and z inform us that they have forgotten their values. This is because we have display turned off for 3x and 4y. Finally, we set x to 5 and y to 3:

A constraint network is an instance of the ConNet class. A constraint network maintains a collection of cells and a collection of constraints. There can be many types of constraints: adders, multipliers, subtractors, dividers, etc. Each constraint maintains a collection of links to its neighboring cells and controls the values those cells may hold. However, a cell has no direct knowledge of its neighboring constraints. Instead, the Publisher-Subscriber pattern is used. Cells are publishers and neighboring constraints are subscribers. The user interface is provided through a command line console linked to the constraint network:

For example, a constraint network representing the equation:

would look like this in memory:

The following sequence diagram shows the constraint network setting the value of x then the value of y:

After the value of x is set, the adder is updated, but the adder does nothing because neither y nor z holds a value. After y is set, the adder is again updated. Now two of its three neighbors holds values, so the adder sets the value of z to x + y.

MainJFrame serves as a base class for all application windows. MainJFrame extends JFrame and handles window closing events by terminating the application. MainJFrame windows are half the size of the screen and are centered on the screen. The MainJFrame class is in my util package.

Monsters

Knights

The Game

Program Output

A UML Class Diagram

Killer Robots

Space Men

The Game

Program Output

Implement and test the power plant example. Add a thermostat class to the example. When the reactor gets too hot, the thermostat is notified and repeatedly decrements the reactor temperature by 3 degrees until the temperature drops below the critical level. Be careful. Each time the thermostat calls the reactor's dec() method, the notifyObservers() method is invoked, which invokes the thermostat's update() method. Soon there will be multiple loops trying to cool the reactor, not to mention lots of extra calls to the update functions of the other subscribers.

Implement your own Publisher class and Subscriber interface. Use Java's List collection to hold subscriber references and an Iterator to notify subscribers. Test your implementation by replacing Observer by Subscriber and Observable by Publisher in the power plant example.

Finish the implementation of ConNet and test it with the equation:

Add a constraint to ConNet that squares a number. Test it with the equation:

The Publisher-Subscriber pattern is an instance of a general class of architectures called Event Notification Systems. In general, these systems provide indirect communication between sender objects (e.g., publishers) and receiver objects (e.g., subscribers). Indirect communication promotes decoupling between senders and receivers and allows senders to broadcast messages. (Events have sources but not destinations, while messages have sources and destinations.)

Event managers are another example of an event notification system. They are used when multiple devices need to be monitored. They are closely related to Application coordinators (see [LAR]), the Event Delegation Model used by Java's abstract window's toolkit (AWT), View Managers (see chapter six), and message dispatchers (see chapter seven).

Using the class diagram as a guide, implement the following classes:

Hint:

Try using the List interface from the Java Collections Framework to implement the event manager's registered listeners. Typical event types are strings and integers.

Test your implementation by modeling a situation where multiple sensors (listeners) monitor multiple nuclear reactors (sources). Assume nuclear reactors have two critical temperatures:

Certain background services may need to be performed each time a word processor document is modified by the user. These services include spell checking, grammar checking, repagination, backing up the document, and re-hyphenation. Of course other background services could be included as new, third-party components are added to the word processor. Naturally, the word processor document must be decoupled from the background services. Draw a UML class diagram showing how you would solve this problem. Your diagram should include the following classes: Document, SpellCheck, GrammarCheck, Paginator, BackUp, and Hyphenator.