The Observer Pattern

CSCI 3132 Summer 2011

Seven Sins of Design

Rigidity make it hard to change Fragility make it easy to break Immobility make it hard to reuse Viscosity make it hard to do the right thing Needless Complexity over design Needless RepeAAon error prone Not doing any
2

The Rules
Apply Common Sense Dont get too dogmaAc / religious Every decision is a tradeo All other principles are just that
Guidelines best pracAces Consider carefully if you should violate them - but, know you can.
3

Open Closed Principle

SoRware enAAes ( Classes, Modules, Methods, etc. ) should be open for extension, but closed for modicaAon. Also Known As Protected VariaAon QuesAon: This principle is applied to which of the design paZerns we have learned so far?

Single Responsibility Principle

A Class should have one reason to change
A Responsibility is a reasons to change

Can be tricky to get granularity right Single Responsibility = increased cohesion Not following results in needless dependencies
More reasons to change. Rigidity, Immobility

QuesAon: This principle is applied to which of the design paZerns we have learned so far? 5

Consider the Following ApplicaAon

Humidity Temperature Pressure Weather StaAon Three Displays

Weather Data Object

6

Whats Given
The WeatherData class has geZer methods that obtain measurement values from temperature, humidity and pressure. The class has a measurementsChanged() method that updates the three values. Three displays must be implemented: current condiAons, staAsAcs and forecast display. System must be expandable other display elements maybe added or removed.
7

A First AZempt
class WeatherData{! public: ! ! void measurementChanged(){! ! ! float temp = getTemperature();! ! ! float humidity = getHumidity();! ! ! float pressure = getPressure();! ! ! currentConditionsDisplay.update(temp,humidity, !! ! ! ! ! pressure)! ! ! ! statisticsDisplay.update(temp,humidity,pressure)! ! !! forecastDisplay.update(temp,humidity,pressure)! }! ! //other WeatherData methods here! }; !
8

The Observer PaZern Observed

Cat Subject Dog Cat Duck Subject o O bject Object bject Object B is roadcasts u dR pdated e-registers egisters R Registers egisters Observers
Dog Object 8 8 Cat Object Duck Object
Other examples: publish and subscription services; eBay

2 Subject Object int int 8 2

Cat Object

Another Example
Handling the addiAon of new customers: Sending a welcome leZer Verify the customers address with the post oce

10

A First Try
Customer: When a customer is added, this object will make the calls to the other objects to have the corresponding acAons take place WelcomeLeZer: Creates welcome leZers for customers that let them know they were added to the system. AddrVericaAon: This object will verify the address of any customer that asks it to

11

Decoupling
We do not want to change the broadcasAng object every Ame there is a change to the set of objects listening to the broadcast. We want to decouple the noAfy-ers (subject) and the noAfy- ees(observer). Two things vary Dierent kinds of objects ones that need to be noAed of a change in state. Dierent interfaces Each object that requires noAcaAon may have a dierent interface. 12

A BeZer SoluAon
All observers must have the same interface. All observers must register themselves. This makes them responsible for knowing what they are watching for. We must add two methods to the subject. attach(Observer) adds the given observer to its list of observers. detatch(Observer) removes the given observer from its list of observers. The observer must implement a method called update. The subject implements the notify method that goes through its list of Observers and calls this update method for each of them.
13

The Class Diagram

14

Example (Contd)
class Customer{! public:! void attach( Observer *myObserver);! void detach( Observer *myObserver);! void notify();! private:! vector<Observer*> myObs;! };! void Customer::attach( Observer *myObserver)! {! myObs.push_back( myObserver);! }!

15

Example (Contd)
void Customer::detach( Observer *myObserver){! for (int i= 0; i< myObs.size(); i++){! if (myObs[i]== myObserver){! myObs.erase(myObs.begin()+i);! return;! }! }! }! void Customer::notify(){! for (int i= 0; i< myObs.size(); i++){! myObs[i]->update(this);! }! }!

16

DeniAon
The observer paZern implements a one-to-many relaAonship between a set of objects. A single object changes state and updates the objects (dependants) that are aected by the change. The object that changes state is called the subject and the other objects are the observers.

17

Loose Coupling
Subjects and observers are loosely coupled. The subject only knows the observer interface and not its implementaAon. Observers can be added and removed at any Ame. In adding new observers the subject does not need to be modied. Subjects and observers can be reused independently. Changes to the subject or observer will not aect the other.
18

Design Principle
Strive for loosely coupled designs between objects that interact. Loosely coupled designs allow us to build exible object-oriented systems. These systems can handle change because they minimize the interdependency between objects.

19

Observer Applicability
Use the Observer paZern in any of the following situaAons When an abstracAon has two aspects, one dependent on the other. EncapsulaAng these aspects in separate objects lets you vary and reuse them independtly. When a change to one object requires changing others, and you do not know how many objects need to be changed. When an object should be able to noAfy other objects without making assumpAons about who these objects are. 20

Observer ParAcipants
Subject
Knows its observers. Any numberof Observer objects may observe a subject. Provides an interface for aZaching and detaching Observer Objects.

Observer
Denes an updaAng interface for objects that should be noAed of changes in a subject

21

Observer ParAcipants
ConcreteSubject
Stores a state of interest to ConcreteObserver objects. Sends a noAcaAon to its observers when its state changes.

ConcreteObserver
Maintains a reference to a ConcreteSubject object Stores state that should stay consistent with the subject state. Implements the Observer updaAng interface to keep its state consistent with the subject state. 22

 Weather StaAon Class Diagram

23

The Observer PaZern: Key Features

Intent: Dene a one-to-many dependency between objects so that when one object changes state, all its dependents are noAed and updated automaAcally. Problem: You need to noAfy a varying list of objects that an event has occurred. Solu.on: Observers delegate the responsibility for monitoring for an event to a central object: The subject.

24

The Observer PaZern: Key Features

Implementa.on: Have objects (Observers) that want to know when an event happen aZach themselves to another object (Subject) that is watching for the event to occur or that triggers the event itself. When the event occurs, the Subject tells the Observers that it has occurred. The Adapter paZern is someAmes needed to be able to implement the Observer interface for all the Observer- type objects.

25

Observer PaZern: Class Diagram

26

Observer Sequence Diagram

ConcreteSubject Object ConcreteObserver ConcreteObserver ObjectA ObjectB SetState() Notify() Update() GetState() Update() GetState()
27

Observer Consequences
Abstract coupling between Subject and Object
All a subject knows is that it has a list of observers, each conforming to the simple interface of the abstract Observer class. The subject does not know the concrete class of any observer.

Support for broadcast communicaAon

Unlike and ordinary request, the noAcaAon that a subject sends need not specify its receiver. The noAcaAon is broadcast automaAcally to all interested objects that subscribed to it.
28

Observer ImplementaAon
How to noAfy - Approach 1
void ConcreteSubject::setstate(int newstate) { state_=newstate; notify(); // notify all observers that // state has changed } Subject s1; subject.setstate(6); // automatic call to notify Subject.setstate(5);
29

Observer ImplementaAon
How to noAfy - Approach 2
void ConcreteSubject::setstate(int newstate) { state_=newstate; } Subject s1; subject.setstate(6); subject.setstate(5); Subject.notify(); // explicit call to notify
30

Observer ImplementaAon
the Push model and the Pull model
ImplementaAons of the Observer paZern oRen have the subject broadcast addiAonal informaAon about the change. The subject passes this informaAon as an argument to Update. Push model: the subject sends obervers detailed informaAon about the change Pull model: the subject sends only a minimal noAcaAon and observers ask for details explicitly 31

Observer ImplementaAon
What happens when we add new observers? Imagine adding the ability to send a leZer with coupons to customers located within 20 miles of one of the companys Brick and Mortar stores.

32

Observer ImplementaAon
If the class we want to add already exists and we can not modify it, then we can adapt it as shown below:

33