1. Slide design: Dr. Mark L. Hornick
SE-2811
5/28/2018
Week 4, Day 1: Threads
[This slide added after class]
Today
2nd example of the Factory Method Pattern
The Observer pattern
17q2 1-3,6-7,9-12
SE-2811
Slide design: Dr. Mark L. Hornick
Content: Dr. Hornick
Errors: Dr. Yoder
Dr. Yoder

2. Motivating application: Microsoft Word
How to update toolbars every time user clicks somewhere different in the document? [Demo]
SE-2811
Dr. Mark L. Hornick

3. Solution 1: (What can be improved?)
public void onClick(ClickEvent e) { if(cursorInBoldText()) { boldButton.setHighlight(); } styleDialog.setStyle(getCurrentCursorStyle()); if(selection.isActive()) { copyButton.setActive(); } /*… etc. … */
SE-2811
Dr. Yoder

4. 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
SE-2811
Slide content originally by Dr. Hornick

5. What are we trying to achieve with the Observer Pattern ?
Separation of software subsystems
Separation between GUI & Domain objects
Loosely-coupled classes to …
Avoid editing code in multiple places
Increase reusability
Increase understanding
Avoid polling
A generic/elegant way for the classes to communicate
SE-2811
Slide content originally by Dr. Hornick

6. 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.
SE-2811
Slide content originally by Dr. Hornick

7. Slide content originally by Dr. Hornick
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.
SE-2811
Slide content originally by Dr. Hornick

8. Slide content originally by Dr. Hornick
Generic Observer
class ObserverClass implements Observer {
public ObserverClass();
public void update(???); }
What is the appropriate argument for the update() method?
SE-2811
Slide content originally by Dr. Hornick

9. Basic class relationships
Subject
attach():void detach():void notifyObservers():void
-observers
Observer
update(???):void
0..*
SubjectClass
ObserverClass1
ObserverClass2
SE-2811
Slide content originally by Dr. Hornick

10. Collaborations between objects in the Observer pattern
s:SubjectClass
o1:ObserverClass1
o2:ObserverClass2
attach()
attach()
notifyObservers()
update(???)
getContextSpecificInfo()
update(???)
getContextSpecificInfo()
SE-2811
Slide content originally by Dr. Hornick

11. LinearSubject example
[write notes on back page, see code online]
SE-2811
Dr. Mark L. Hornick

12. 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() {…}
... }
SE-2811
Slide content originally by Dr. Hornick

13. Slide content originally by Dr. Hornick
Example (contd.)
public void acquireDataFromSensors() {
// acquire updated weather data ……
notifyObservers(); // notify observers }
SE-2811
Slide content originally by Dr. Hornick

14. Slide content originally by Dr. Hornick
Example (contd.)
class mainDisplay extends Observer {
public mainDisplay (WeatherData wd){...}
public void update(???) {...}
public void updateDisplayUI() {...} }
SE-2811
Slide content originally by Dr. Hornick

15. Slide content originally by Dr. Hornick
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
SE-2811
Slide content originally by Dr. Hornick

16. 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?
SE-2811
Slide content originally by Dr. Hornick

17. 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
SE-2811
Slide content originally by Dr. Hornick

18. 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
SE-2811
Slide content originally by Dr. Hornick

19. 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.
SE-2811
Slide content originally by Dr. Hornick

20. SE-2811
5/28/2018
SE-2811
Dr. Mark L. Hornick
Dr. Yoder