The Observer Pattern

1. The Observer Pattern SE-2811 Dr. Mark L. Hornick

2. Observer Pattern Context A system contains objects exhibiting: • One-to-many dependency between objects • One object changes state • All dependents are notified and updated automatically

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

4. Key components in the Observer Pattern • Subject • Subject has dependent observers. • Observer(s) • When the state of the subject changes, each dependent observer is notified.

5. Generic Subject class class SubjectClassimplementsSubject { public SubjectClass(); public void attach(Observer obs); public void detach(Observer obs); public void notifyObservers(); private ArrayList<Observer> observers; } 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.

6. Generic Observer class ObserverClassimplementsObserver { public ObserverClass(); public void update(???); } What is the appropriate argument for the update() method?

7. Basic class relationships Subject ------------------------------ attach():voiddetach():voidnotifyObservers():void Observer---------------- update(???):void -observers 1..* SubjectClass ObserverClass1 ObserverClass2

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

9. Weather Program example class WeatherData implements Subject { //private data attributes List<Observer> observers; ... public WeatherData(){…} public void getTemp() {…} public intgetWindSpeed() {…} public void attach(Observer obs) {…} public void detach(Observer obs) {…} public void notifyObservers() {…} ... }

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

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

12. Example (contd.) public mainDisplay(WeatherData wd) { SubjectwdSubject = 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 }

13. Implementation Questions What should be the arguments of the update method? Should we send the Subject as the argument? 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?

14. 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 • Minimal • Abstract

15. Consequences (positive) Cohesion is increased from single-class implementation • State management and display/response are separated • E.g. GUI innards separated from “your code” • E.g. Web access separated from display

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