The Observer pattern defines a one-to-many dependency between a subject and observer objects, such that when the subject's state changes, all observer objects are notified and updated automatically. The pattern includes roles for a subject, concrete subject, observer, and concrete observer. It allows for loose coupling between subjects and observers by having subjects notify observer objects of state changes without knowing the concrete classes of observers. The pattern is applicable when an abstraction has dependent aspects and subjects should be able to notify observers without knowledge of who the observers are.

1. OBSERVER DESIGN
PATTERN
Presented by:
Rohan S Thingalaya
1MS09IS079

2. Contents
Definition
Participants
Structure
Motivation
Example
Applicability
Implementation issues
Consequences

3. Definition
The Observer Pattern defines a one-to-many
dependency between a subject object and any
number of observer objects so that when the
subject object changes state, all its dependents are
notified and updated automatically
Also Known As : Dependents, Publish-Subscribe

4. Participants
 Subject
◦ the object which will frequently change its state
and upon which other objects depend.
◦ Knows its observers and Can have any number
of observers
◦ Provides an interface for attaching and detaching
observer objects
 Observer
◦ the object which depends on a subject and
updates according to its subject's state.
◦ Defines an update interface for objects that
should be notified of changes in subject

5.  Concrete Subject
◦ Store state of interest for concrete observer
objects
◦ Send notification to observer objects when state
changes
 Concrete Observer
◦ Maintains reference to Concrete Subject object
◦ Stores state that should be consistent with the
subject’s state
◦ Implement update operation

6. Structure

7. Motivation
 Partitioning a system into a collection of co-
operating classes requires maintaining consistency
between related objects
 Achieving such consistency by making tightly-
coupled 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.

8. Example
 The observer pattern is not limited to single user
interface components. For example you could have
a part A in your application which displays the
current temperature.
 Another part B displays a green light if the
temperature is above 20 degree celsius. To react to
changes in the temperature part B registers itself as
a listener to Part A.
 If the temperature in part A is changed, an event is
triggered. This event is sent to all registered
listeners, as for example part B. Part B receives the
changed data and can adjust its display.

9. Observer Pattern - Example

10. Applicability
Use the Observer Pattern when…
 The abstraction has two aspects with one
dependent on another
 The subject object does not know exactly how
many observer objects it has
 Subject object should be able to notify it’s observer
objects without knowing who these observer
objects are i.e. the objects need to be de-coupled

11. Implementation Issues
 Mapping subjects to their observers: a subject can keep
track of it’s list of observers as observer reference
or in a hash table
 Observing more than one subject: In some cases it
may make sense to have a many-to-many
relationship between subjects and observers. The
Update interface in the observer has to know
which subject is sending the notification
 Who triggers the Update: 2 options – state setting
operation in the subject to trigger notify or
Observer to trigger notify

12.  Dangling references to deleted subjects: Deleting a
subject or observer should not produce dangling
references. Subjects should notify observers so that
they may reset their references. Observers also
cannot be simple deleted as other subjects may be
observing them
 Make sure that subject state is self-consistent before
notification: else an observer may query the
intermediate state
 Specifying modifications of interest explicitly: Observer
could be registered only for specific events

13. Consequences
 Abstract coupling between subject and observer:
Subjects know that they have a list of observers
each conforming to a simple interface of the
abstract Observer class. Subject has no knowledge
of the concrete class of any observer. Thus,
coupling between subject and observer is abstract
and minimal. As there is no tight coupling, each
can be extended and reused individually.
 Dynamic relationship between subject and observer: can
be established at runtime giving programming
flexibility

14.  Support for broadcast communication: A notification is
broadcast automatically to all interested objects
that are subscribed to a subject.
 Unexpected Updates: Observers have no knowledge
about each other and are blind to the cost of
changing the subject. A seemingly innocuous
operation on the subject may cause a series of
updates in the observers and their dependent
objects. With a dynamic relation between the
subject and the observer, the update dependency
may be hard to track down.

15. Thank You