8. Observer Pattern SE2811 Software Component Design Dr. Rob Hasker (based on slides by Dr. Mark Hornick) 8. Observer Pattern

Problem: Information to multiple clients Consider what happens when move cursor in MSWord Enable, disable bold/italic/superscript/underline/etc. Update font, size Update centering/left justification/right justification How would this be implemented? How to get a message to all students? What if only some students want messages from me? Is there a better way? Discuss and present! Publish/subscribe model

Observer Pattern Context Core idea: One-to-many dependency between objects One object changes state All dependents are notified and updated automatically

Observer pattern: key components Subject Subject has dependent observers. Observer(s) When the state of the subject changes, each dependent observer is notified.

What are we trying to achieve with the Observer Pattern ? Separation of software subsystems Separation between GUI & Domain objects Loosely-coupled classes Because tightly-coupled classes reduce reusability & understanding A generic/elegant way for the classes to communicate

Generic Subject class class SubjectClass implements Subject { public SubjectClass(); public void attach(Observer obs); public void detach(Observer obs); public void notifyObservers(); private ArrayList <Observer> observers; } Subject::attach(Observer* pObserver) { m_hObservers.push_back(pObserver); } Subject::detach(Observer* pObserver) m_hObservers.remove(pObserver); Subject::notify() Vector<Observer*>::iterator m_ppObserver; for (m_ppObserver = m_hObservers.begin();m_ppObserver = m_hObservers.end(); ++m_ppObserver) (*m_ppObserver)->update(); Note: Some texts define a notify() instead of notifyObservers() method. However, Java’s Object class already has a notify() method, which we don’t want to override.

Generic Observer class ObserverClass implements Observer { public ObserverClass(); public void update(???); } Key question: What is the appropriate argument for the update() method?

Basic class relationships

Collaborations between objects in the Observer pattern s:SubjectClass o1:ObserverClass1 o2:ObserverClass2 attach() attach() notifyObservers() update(???) getContextSpecificInfo() update(???) getContextSpecificInfo()

Weather Program example class WeatherData implements Subject { //private data attributes List<Observer> observers; ... public WeatherData(){…} public void getTemp() {…} public int getWindSpeed() {…} public void attach(Observer obs) {…} public void detach(Observer obs) {…} public void notifyObservers() {…} ... } See sample code (available on website) original_weather: must update both revised_weather: uses observer note Observer, Subject classes weather program, original: no observer; must update both panels; revised: implements observer pattern

Example (contd.) public void acquireDataFromSensors() { // acquire updated weather data …… notifyObservers(); // notify observers }

Example (contd.) class mainDisplay extends Observer { public mainDisplay (WeatherData wd) {...} public void update(???) {...} public void updateDisplayUI() {...} }

Example (contd.) public mainDisplay(WeatherData wd) { Subject wdSubject = wd; wdSubject.attach(this); } // What do we pass to update()? public void update(???) // How do we get data from the Subject? updateDisplayUI(???); // mainDisplay class method

Implementation Questions What should be the arguments of the update method? Should we send the Subject as the argument? Alternatives: pull vs. push – which was used in the weather example? What would be the danger of pushing simple data to observers? Should each instance of the Observer store the “concrete subject” as a data attribute, or just an Interface reference? Can Subject be an abstract class instead of an Interface?

Consequences (positive) Coupling between Subject and Observers: Subject knows it has a list of Observers, but not specific classes Each Observer conforms to the simple interface of the abstract Observer Interface. Hence, coupling is Abstract Minimal Cohesion: observers highly cohesive – no code to monitor multiple places; subjects don’t have code checking on observers, so also cohesive

Consequences (negative) Broadcast communication Notification is broadcast to all interested objects. Observers can be added/removed at any time. Observer decides when it needs to be notified. Unexpected updates Observers have no knowledge Of each other’s presence. About the cost of “state change of subject” Cascade of updates.

Observer pattern in Java See: Observer, Observable Note discussion of notifyObservers Must call setChanged for notifications to be sent setChanged, clearChanged: can be used to suppress updates Issues Observer is a class – can’t subclass something else Observable.setChanged is protected – must subclass to be useful Doesn’t scale: if have large numbers of observables, type system does little to help What to do?

Review So what’s this pattern about? When to use it? Where can we use interfaces, abstract classes in this pattern? Where must we use them? Why should we consider rolling our own in Java Draw a UML diagram What methods might be private/protected?