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

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

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

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

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

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

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

8. Basic class relationships

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

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

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

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

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

14. 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?

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

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.

17. 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?

18. 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?