Design Pattern: OBSERVER

1
Design Pattern OBSERVER

• John T.E. Timm
• Nitin Sharma
• Kenneth Burnett

2
Intent

• Define a one-to-many dependency between objects
  so that when one object changes state, all its
  dependents are notified and updated
  automatically.
• Also known as Dependents, Publish-Subscribe

3
Motivation

• A common side-effect of partitioning a system
  into a collection of cooperating classes is the
  need to maintain consistency between related
  objects. You dont want to achieve consistency
  by making the classes tightly coupled because
  that reduces their reusability.

4
Applicability

• When abstraction has two aspects, one dependent
  on the other. Encapsulating these aspects in
  separate objects let you vary and reuse them
  independently.
• When a change to one object requires changing
  others, and you don't know how may objects need
  to be changed.

5
Applicability (contd)

• When an object should be able to notify other
  objects without making assumptions about who
  these objects are. In other words, you don't
  want these objects tightly coupled.

6
Structure
7
Participants

• Subject
• knows its observers. Any number of Observer
  objects may observe a subject.
• provides an interface for attaching and detaching
  Observer objects.
• Observer
• defines an updating interface for objects that
  should be notified of changes in a subject.

8
Participants (contd)

• ConcreteSubject
• Stores state of interest to ConcreteObserver
  objects.
• Sends a notification to its observers when its
  state changes.

9
Participants (contd)

• ConcreteObserver
• maintains a reference to ConcreteSubject object.
• stores state that should stay consistent with the
  subjects.
• implements the Observer updating interface to
  keep its state consistent with the subjects.

10
Collaborations
11
Consequences

• Abstract coupling between Subject and Observer.
• Support for broadcast communication.
• Unexpected updates.

12
Implementation

• Issues related to the implementation of the
  dependency mechanism
• Mapping subjects to their observers.
• Observing more than one subject.
• Who triggers the update?
• Dangling references to deleted objects.
• Making sure Subject state is self-consistent
  before notification.

13
Implementation (contd)

• More issues related to the implementation of the
  dependency mechanism
• Avoiding observer-specific update protocols (push
  model, pull model)
• Specifying modifications of interest explicitly.
• Encapsulating complex update semantics.

14
Event Generator Idiom

• Enable interested objects (listeners) to be
  notified of a state change or other events
  experienced by an event generator.
• Difference between an idiom and a design pattern
• Difference in scope
• Pattern problem and solution are generic
  independent of implementation language.
• Idiom low-level pattern specific to a
  programming language

15
Event Generator Idiom (contd)

• Intent
• Enables interested objects (listeners) to be
  notified of a state change or other events
  experienced by an event generator.
• Context
• One or more objects (recipients) need to use
  information or be notified of state changes or
  events provided by another object (the
  information provider).

16
Event Generator Idiom (contd)

• Requirements of this context
• Traditional approach Keeping references to each
  object that is needed to be informed. The
  programmer should know the number and which
  objects would be recipients.
• One or more recipients must be notified of events
  or state changes.
• Number and type of recipient objects unknown at
  compile-time and may vary during execution.
• Recipient and information provider objects are
  loosely coupled.

17
Event Generator Idiom (contd)

• Solution Implement an event delegation
  mechanism between the Event Generator and the
  Listeners.
• Step 1 Define event category classes
• A class for each major category of events
• Each class extends java.util.EventObject
• Encapsulate information to be propagated from the
  observable to the listeners
• Class name ends in Event, e.g. TelephoneEvent

18
Event Generator Idiom (contd)

• Step 2 Define listener interfaces
• Extends java.util.EventListener
• Step 3 Define adapter classes (optional)
• For each listener interface, define an adapter
  class that implements the interface
• Step 4 Define the Observable class
• Define a pair of add/remove methods

19
Event Generator Idiom (contd)

• Step 5 Define the listener Objects
• To be a listener for some event, an objects
  class must implement the listener interface for
  that category of events.

20
Event Generator Idiom (contd)
21
Event Generator Idiom (contd)

• Implementation Guidelines
• Create one event for each firing and pass it to
  the listeners.
• Make the event object immutable. Hence the
  listeners cannot change it.
• Use a single thread to notify all listeners.
• Take a snapshot of the registered listeners when
  the event occurred and notify all the listeners.

22
Event Generator Idiom (contd)

• Implementation Guidelines (contd)
• Keep listeners fast.
• Listeners should not depend upon the order of
  notification.

23
Example MVC Architecture

• Model/View/Controller architecture accommodates
  different views or presentation of the same data
• For instance, you could represent the same data
  with a bar chart, pie chart, or line chart
• Implements the observer pattern which allows it
  to separate the problem into components, and to
  provide dynamic binding between the model and its
  views

24
Components

• Model holds the data and provides an interface
  for changing the data it has no direct
  knowledge of its controllers/views
• View manages the visual display of the data in
  the model it has a reference to the model
• Controller the user interface for making changes
  to the data in the model it also holds a
  reference to the model