Observer

Also known as Publisher-Subcriber

Pattern Properties

Type: Behavioral

Level: Component

Purpose

To provide a way for a component to flexibly broadcast messages to interested receivers.

Introduction

What if an object changed in the forest and nobody noticed?

Suppose you want to let Personal Information Manager users share information. This would be useful, for instance, for coordinating a regular club meeting (Organized Organization for Zebra Encoders). You could use an Appointment object to provide club members with current information about the meeting location, date and time. However, how do you ensure that, if the meeting time changes, a change to the appointment information is sent to everyone who's interested? (What if you held a meeting and nobody came?)

You could maintain a list of all club members and send every member the updated information. This would be appropriate if attending each meeting were required, but this isn’t the case, and it seems wasteful to update everyone when some members might not choose to attend. From a technical viewpoint, such a solution could also be inefficient—for a large club, this could involve a great deal of communication overhead.

It’s better to allow individual users to decide whether to receive information for a particular meeting. An Appointment object is stored on a central server. If club members want to receive updates for the meeting, they register with the server. Anytime the Appointment is updated, the server sends the new information to the currently registered attendees.

This solution, known as the Observer pattern because the central object is being observed by the interested objects, provides great flexibility in sending update information. By making listeners responsible for registering with the object, you reduce the communication overhead to only those participants who actually want to receive the updated information.

Applicability

The Observer is generally appropriate when a system has:

At least one message sender.

One or more message receivers that might vary within an application or among applications.

This pattern is frequently implemented in situations where the message sender does not need or want to know how receivers act upon the information it provides; it is simply concerned with broadcasting information.

Description

Some message senders, also known as message producers, follow a simple point-to-point communication model, creating messages that are intended for single, specific message receivers, or consumers. In these cases, event handling is fairly straightforward. For other kinds of message producers, however, the behavior is not so clear cut. An action can trigger a variable series of reactions, and might involve the producer and one or more consumers.

Consider a customer address. In a business model, a change of address can trigger a wide-ranging set of responses within a system. Customer information might have to be changed, customer subscriptions would have to be updated, orders might have to be modified. Potentially, even information such as shipping cost and sales tax might be affected. The Observable pattern is appropriate for this kind of problem.

In the Observer pattern, the message producers (observable components) send messages that generate events. One or more message receivers (observers) receive and act upon the events. The observable component’s

67