changes its state is called the subject , whereas those objects that receive notii cation of the change
are called the observers . The relationship is one to many, with the subject having many observers.
Imagine a chat application that automatically refreshes every second so it can check for new
messages. Also imagine that it has a chat room feature allowing many people to chat together. Each
of these chat clients regularly checks with the server to see if there has been a new message posted
by one of the other clients. As you can imagine, this is not very performance friendly. Would it not
make much more sense if the newly sent message was “pushed” to all subscribed clients? It would
certainly be more efi cient. The observer pattern can solve this problem. Here, the observer would
be the chat server, and each client would be a subject. The server would be registered with each
client, and when the client posts a new message (a change in state of the subject), the subject would
call a method on the server to notify it of the new message. Then the server would call a method on
all its registered clients and send the message to each one.
NOTE The observer pattern is also referred to as the Hollywood principle,
whose motto is “don't call us; we'll call you.” This is not surprising; most
Hollywood agents would prefer to call clients for a new role rather than being
hounded by clients calling them. This system works well because there's never a
perfect time to call an agent to check about an available job. You'll likely either
miss out on a job if jobs arrive more frequently than you're calling, or you'll be
seen as obnoxious if you're calling more often than jobs arrive.
With the help of the observer pattern, an agent calls appropriate clients just as a
new job opens, without losing time or wasting resources.
The GoF 1 book states that the observer pattern “dei nes a one‐to‐many dependency between objects
so that when one object changes state, all its dependents are notii ed and updated automatically.”
The Head First Design Patterns 2 book gives the example of a weather monitoring application
that sends a notice when temperatures change. The observer pattern is based on the principle of
inheritance and is one of the behavioral design patterns.
To be an observer, each concrete observer implementation needs to share a similar interface. The
subject lets each observer add itself to a registry. When the subject changes, the observer calls each
subject's registered implementation to notify the observer about the changes.
This is an efi cient implementation because only one call happens for each observer at the time
of the change. A naive solution such as regularly checking the subject may produce an unlimited
number of calls from different observers even though there had been no change to the object
The observer pattern is not that different from a news subscription. Objects that want to subscribe
to changes on another object register themselves to receive news of those changes. Rather than
checking the target object, these objects are called when there is a change.