Behavioral Patterns  «Prev  Next»
Lesson 5Observer: motivation
ObjectiveDefine the Motivation of the Observer pattern.

Observer Pattern Motivation

Motivation for Observer Pattern
It is not uncommon for one object in a system to want to know about changes in the state of another object in the system.
For instance:
  1. A fax modem program should know when the serial port state changes, indicating an incoming call.
  2. A document needs to know when the state of the FontDialog object changes from Times to Helvetica.

In the case of the course project, vehicle queues need to know when the state of the light changes. The VehicleQueue could run a thread that keeps checking the light, but it is simply too much to ask an object to check constantly the state of some other object, just because it wants to know when the object changes. The solution is that the changed object should take responsibility for notifying other objects that it has changed. Assuming reasonable data encapsulation has been used, the only way the object's state can be changed is by invoking methods in the object. All that is needed is a little extra code added to each method to notify other objects that it has changed. This is called the Observer pattern. Use the Observer pattern when:
  1. The changes to one object imply possible changes in other objects.
  2. The object that changes does not know at compile time exactly which other objects need to be notified of its changes.

In our new, more sophisticated windowing world, we often would like to display data in more than one form at the same time and have all of the displays reflect any changes in that data. For example, you might represent stock price changes both as a graph and as a table or list box. Each time the price changes, we would expect both representations to change at once without any action on our part. We expect this sort of behavior because there are any number of Windows applications, like Excel, where we see that behavior. Now there is nothing inherent in Windows to allow this activity and, as you may know, programming directly in Windows in C or C++ requires a certain amount of skill. In Java, however, we can easily make use of the Observer Design Pattern to cause our program to behave in this way. The Observer pattern assumes that the object containing the data is separate from the objects that display the data, and that these display objects observe changes in that data. This is simple to illustrate as we see below.


The "Data" is separate from the Graphics and List Display

When we implement the Observer pattern, we usually refer to the data as the Subject and each of the displays as Observers. Each of these observers registers its interest in the data by calling a public method in the Subject. Then, each observer has a known interface that the subject calls when the data change. We could define these interfaces as follows:

abstract interface Observer {
  //notify the Observers that a change has taken place
  public void sendNotify(String s);
}
//-----
abstract interface Subject {
  //tell the Subject you are interested in changes
  public void registerInterest(Observer obs);
}

The advantage of defining these abstract interfaces is that you can write any sort of class objects you want as long as they implement these interfaces, and that you can declare these objects to be of type Subject and Observer independent of what else they do.