Java Reference
In-Depth Information
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
