Chapter 16. The Observer Design Pattern

[The Observer pattern defines] a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

”from Design Patterns: Elements of Reusable Object-Oriented Software (the so-called GoF book discussed in Chapter 15)

Effectively, the Observer pattern is an all-purpose event-broadcasting mechanism. It lets a class broadcast generic updates to registered listeners, much as you could ask your local movie retailer to call you when a DVD you're interested in arrives. It could be used in anything from a mail application (when a new email is received) to a video game (when an enemy dies).

In the Observer pattern, changes in the state of one object (the subject ) are broadcast to other interested objects (the observers ). Each observer object indicates that it is interested in receiving broadcasts by registering with the subject. When the subject changes, it tells its current list of observers that it changed.

The Observer pattern is perfect for rendering multiple representations of a single body of data. For example, consider a weather-reporting application with a class, WeatherReporter , that stores the latest weather report. On screen are two representations of the weather report, each handled by its own class. The TextReport class describes the weather in text, such as:

Temperature: 29C, Probability of Precipitation: 20%

A separate GraphicReport class represents the weather with icons (a thermometer icon for temperature and a pie chart for the probability of precipitation).

When the weather application starts, instances of TextReport and GraphicReport register to receive updates from the WeatherReporter object. When the weather data changes, the WeatherReporter (the subject) broadcasts the latest weather to its list of observers, in this case the TextReport and GraphicReport instances. Each object is responsible for independently handling the update in its own way. The TextReport instance generates a text message whereas the GraphicReport instance displays weather icons. New classes can be added to the application at any time to handle the weather data in other ways. For example, a SoundReport class could play the sound of rain when it's raining, and an EmailReport class could use a server-side script to send out email when the weather report is updated.

Importantly, nothing about the WeatherReporter class needs to change to allow new types of observers to receive updates from it. Observer classes can be added, changed, and removed without affecting any other part of the application. Furthermore, the WeatherReporter class doesn't need to know the identity of the listeners (observers), such as the TextReport and GraphicReport classes. The datatype of the observers doesn't matter as long as they can handle updates provided by WeatherReporter . In other words, in the Observer pattern, the subject and its observers are loosely coupled , making the application easy to modify and extend. If we weren't using the Observer pattern, we might tightly couple the WeatherReporter class with the TextReport and GraphicReport classes. We might have the WeatherReporter class invoke methods found only in those classes, such as TextReport.updateTextOutput( ) and GraphicReport.changeWeatherIcons( ) . In this hypothetical, tightly coupled implementation, our architecture is much more difficult to change. If we want to add a new output class, we have to change WeatherReporter to call the new class's specific update method. And if we want to change the name of, say, GraphicReport.changeWeatherIcons( ) , we have to update the code that calls that method in WeatherReporter . The Observer pattern protects us from that work.

Figure 16-1 depicts the general relationships between the WeatherReporter , TextReport , and GraphicReport objects in our hypothetical weather application.

Figure 16-1. Observer pattern weather application example

Now let's take a look at how to implement the Observer pattern, first by studying its general structure, then by creating a real example ”an application log. As we progress through the chapter, try to remember the simplicity of the pattern. If you feel bogged down by code details, come back to Figure 16-1Figure 16-1 and remind yourself that in the Observer pattern we're just trying to make one class broadcast changes to other classes. Once we establish a code base for the pattern, it takes relatively little effort to create new implementations of Observer.

The source code discussed in this chapter is available at http:// moock .org/eas2/examples.