The Observer pattern defines a one-to-many dependency between a subject and any number of observers, such that when the subject's state changes, all observers are notified and updated automatically. It allows one to vary and reuse subject and observer objects independently. The pattern decouples subjects and observers, with subjects maintaining references to observers and notifying them of state changes via a common interface. It is used when a change to one object requires changing others and the number changing is unknown.

1. Observer pattern
Prepared by:
Samreen Farooq

2. INTENT
The Observer Pattern defines a one-to-many
dependency between a subject and any number of
observer so that when the subject object changes
state, all its dependents are notified and updated
automatically.
Also Known As : Dependents,
Subscribe, Delegation Event Model
University of Engineering and Technology
Publish-
2

3. MOTIVATION
 Partitioning a system into a collection of cooperating classes requires maintaining
consistency between related objects.
 Achieving such consistency by making tightlycoupled classes reduces their re-usability
 Two parts to the Observer Pattern
 Subject
 Observer
 Relationship between subject and observer is
one-to-many; it needs to be de-coupled to make
the subject and observer independently reusable.
University of Engineering and Technology
3

4. EXAMPLE
 Suppose you have some data that can be
displayed by a table, a bar graph or a pie chart.
 Changes to the underlying data should be
reflected in all three of the displays
 This is where the Observer Design Pattern
comes in handy.
University of Engineering and Technology
4

5. EXAMPLE
.
Relative Percentages
A B C D
X
15 35 35 15
Y
10 40 30 20
Z
10 40 30 20
A
Change notification
D
B
C
A
B
C
D
A=10%
B=40%
C=30%
D=20%
Application data
Requests, modifications
University of Engineering and Technology
5

6. Use the Observer Pattern when…
 The abstraction has two aspects with one dependent
on another.
 The subject does not know exactly how many
observer it has.
 Subject should be able to notify it’s observers without
knowing who these observers are i.e. the objects
need to be de-coupled
University of Engineering and Technology
6

7. Generalized Structure
observers
Subject
Observer
attach (Observer)
detach (Observer)
Notify ()
Update()
For all x in observers{
x  Update(); }
Concrete Observer
Concrete Subject
GetState()
SetState()
subjectState
subject
Update()
observerState
observerState=
subject  getState();
University of Engineering and Technology
7

8. Generalized Structure (cont.)
• Subject
 Interface for Concrete Subjects
 Requires implementations to provide at least the
following methods:
 subscribe / attach
 unsubscribe / detach
 notify all observers of state changes
• Concrete Subject
 Implements the Subject interface
 Maintains direct or indirect references to one or more
Concrete Observers
 Keeps track of its own state
 When its state changes it sends a notification to all of
its Observers by calling their update() methods
University of Engineering and Technology
8

9. Generalized Structure (cont.)
Observer
 Interface for Concrete Observer objects
 Requires an update method
Concrete Observer
 This is the actual object that is observing the
state of the Concrete Subject.
 The state that it maintains should always be
consistent with the state of its Subject.
 Implements update() method.
University of Engineering and Technology
9

10. When to use the Observer
Pattern?

When an abstraction has two aspects: one dependent on
the other. Encapsulating these aspects in separate
objects allows one to vary and reuse them
independently.

When a change to one object requires changing others
and the number of objects to be changed is not known.

When an object should be able to notify others without
knowing who they are. Avoid tight coupling between
objects.
University of Engineering and Technology
10

11. Pros & cons
Pros:
 Decoupling of subject and observer, each can be
extended and reused individually.
 Dynamic addition and removal of observers at
runtime.
 Subject broadcasts notification automatically to all
interested objects, no matter how many or which kind
of observers are registered.
Cons:
 May result in many notifications the observers are
not interested in
 Potentially difficult for the observers to figure out the
specific state change of the subject.
University of Engineering and Technology
11

12. Application problem
Subscriber for
sports
Subscriber for
Politics
News
Paper
Object
Subscriber for
job ads
University of Engineering and Technology
12

13. Problem solution through
observer
Subscriber
for sports
<<interface>>
Subscriber for
Politics
News
Paper
Publisher
News Paper
Object
Subscriber
for job ads
University of Engineering and Technology
13

14. Push model
News Paper Object
<<interface>>
News Paper Publisher
Update(Sports, Politics,
Update(Sports, Politics,
JobAds)
JobAds)
Subscriber
for sports
Subscriber for
Politics
University of Engineering and Technology
Subscriber
for job ads
14

15. Pull model
News Paper Object
<<interface>>
Weather Station
Notify Change()
getSports
Update()
Subscriber
for sports
getPolitics
Update()
getJobAds
Update()
Subscriber for
Politics
Subscriber
for job ads
University of Engineering and Technology
15

16. Push vs. pull model
Pull Model
Push Model
Subject sends indication to Observer about
change.
Subject sends all information about changes
to Observers.
Public methods of Subject are used to query.
Pushes information to the Observer as
parameter with the update() method.
Observer pull information from the Subject
to effect any relevant changes
Requires assumptions about what the
Observers need to know.
Subject requires fewer assumptions about
what the observers want to know
May need to allow for subscription to
relevant changes only, but this adds
complexity
In pull model observers have global visibility In push model subject has attribute visibility
of subject.
of all of it observers.
University of Engineering and Technology
16

17. University of Engineering and Technology
17