The Observer Design Pattern Presented By: Manali Joshi

1
The Observer Design PatternPresented
ByManali Joshi
2
Intent

• 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

3
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.

4
Example

• Spreadsheet Program

5
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 its
  observer objects without knowing who these
  observer objects are i.e. the objects need to be
  de-coupled

6
Structure
7
Participants

• Subject
• Knows its observers
• Can have any number of observers
• Provides an interface for attaching and detaching
  observer objects
• Observer
• Defines an update interface for objects that
  should be notified of changes in subject
• 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
  subjects state
• Implement update operation

8
Collaborations

• Concrete Subject notifies its observers whenever
  a change occurs that could make its observers
  state inconsistent with its own
• After this, a Concrete Observer may query the
  subject for information and then change its
  internal state accordingly

9
Implementation Issues

• Mapping subjects to their observers a subject
  can keep track of its 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

10
Implementation Issues contd. ..

• 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

11
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
• 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.

12
Related Patterns

• Mediator Define an object that encapsulates how
  a set of objects interact. Mediator promotes
  loose coupling by keeping objects from referring
  to each other explicitly, and it lets you vary
  their interaction independently.
• Singleton Ensure a class only has one instance,
  and provide a global point of access to it.

13
References

• http//www.wohnklo.de/patterns/observer.html
• http//sern.ucalgary.ca/courses/SENG/609.04/W98/la
  msh/observerLib.html
• http//page.inf.fu-berlin.de/bokowski/Observer.ht
  ml

14
Questions