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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SE-2811 5/28/2018 https://www.polleverywhere.com/free_text_polls/zIp2tH2IVWjXv4H SE-2811 Dr. Mark L. Hornick Dr. Yoder