Week 6 Class 2 Observer Pattern l Today

Week 6, Class 2: Observer Pattern l Today l l The Observer pattern Half-Exam 2: l Week 7 Friday SE-2811 Slide design: Dr. Mark L. Hornick Content: Dr. Hornick Errors: Dr. Yoder 1

If you think the internet is not working in its current incarnation, you can’t change the system through think-pieces and F. C. C. regulations alone. You need new code [. . . you need cryptocurrency!]. Stephen Johnson, "Beyond the Bitcoin Bubble, ” New York Times, Jan 15 th 2018 SE-2811 Dr. Mark L. Hornick 2

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

Solution 1: (What kind of cohesion is this? ) public void on. Click(Click. Event e) { if(cursor. In. Bold. Text()) { bold. Button. set. Highlight(); } style. Dialog. set. Style(get. Current. Cursor. Style()); if(selection. is. Active()) { copy. Button. set. Active(); } /*… etc. … */ } SE-2811 Dr. Yoder 4

Observer Pattern Context A system contains objects exhibiting: l l l 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 ? l Separation of software subsystems l l Loosely-coupled classes to … l l l Separation between GUI & Domain objects 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 l Subject l l Subject has dependent observers. Observer(s) l When the state of the subject changes, each dependent observer is notified. SE-2811 Slide content originally by Dr. Hornick

Generic Subject class Subject. Class implements Subject { public Subject. Class(); public void attach(Observer obs); public void detach(Observer obs); public void notify. Observers(); private Array. List <Observer> observers; } Note: Some texts define a notify() instead of notify. Observers() 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

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

Basic class relationships SE-2811 Slide content originally by Dr. Hornick 10

Collaborations between objects in the Observer pattern s: Subject. Class o 1: Observer. Class 1 o 2: Observer. Class 2 attach() notify. Observers() update(? ? ? ) get. Context. Specific. Info() SE-2811 Slide content originally by Dr. Hornick 11

Implementation Questions l l l 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: l l l 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 l l Minimal Abstract SE-2811 Slide content originally by Dr. Hornick

Consequences (positive) Cohesion is increased from single-class implementation l l l 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) l Broadcast communication l l 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 l Observers have no knowledge l l Of each other’s presence. About the cost of “state change of subject” Cascade of updates. Subject does not record who is listening to it

Polling without Observer pattern s: Subject. Class o 1: Observer. Class 1 o 2: Observer. Class 2 change. State() get. Context. Specific. Info() 16

Push in Observer Pattern s: Subject. Class o 1: Observer. Class 1 o 2: Observer. Class 2 attach() notify. Observers() update(State cool. Stuff) 17

Pull in Observer Pattern s: Subject. Class o 1: Observer. Class 1 o 2: Observer. Class 2 attach() notify. Observers() update() get. Context. Specific. Info() 18

Comparing Push and Pull l In teams of 2 or 3 Write two lists, one containing the advantages of push, the other, of pull. Write as many advantages as you can in 2 minutes. SE-2811 Dr. Mark L. Hornick 19

Java’s Observer Patterns l Java has multiple implementations of the Observable/Observer pattern l java. util: l l l Observable Observer javafx: l l javafx. scene. control. Button. Base javafx. event. Event. Handler SE-2811 Dr. Mark L. Hornick 20

java. util. Observable l l This “Subject” is a class Advantages: l l Generic implementation (can’t implement in interface) Disadvantages: l l l If you want to inherit from a different class… you can’t Must cast parameter to specific type Don’t get to code from scratch for the learning experience SE-2811 Dr. Mark L. Hornick 21

UML diagram for the Linear. Subject Observer SE-2811 Dr. Mark L. Hornick 22

Implementation Questions l l l What should the arguments of the update method be? 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: l l l 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 l l Minimal Abstract SE-2811 Slide content originally by Dr. Hornick

Consequences (positive) Cohesion is increased from single-class implementation l l l 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) l Broadcast communication l l 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 l Observers have no knowledge l l l Of each other’s presence. About the cost of “state change of subject” Cascade of updates. SE-2811 Slide content originally by Dr. Hornick

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

Weather Program example class Weather. Data implements Subject { //private data attributes List<Observer> observers; . . . public Weather. Data(){…} public void get. Temp() {…} public int get. Wind. Speed() {…} public void attach(Observer obs) {…} public void detach(Observer obs) {…} public void notify. Observers() {…}. . . } SE-2811 Slide content originally by Dr. Hornick

Example (contd. ) public void acquire. Data. From. Sensors() { // acquire updated weather data …… notify. Observers(); // notify observers } SE-2811 Slide content originally by Dr. Hornick

Example (contd. ) class main. Display extends Observer { public main. Display (Weather. Data wd){. . . } public void update(? ? ? ) {. . . } public void update. Display. UI() {. . . } } SE-2811 Slide content originally by Dr. Hornick

Example (contd. ) public main. Display(Weather. Data wd) { Subject wd. Subject = wd; wd. Subject. attach(this); } // What do we pass to update()? public void update(? ? ? ) { // How do we get data from the Subject? update. Display. UI(? ? ? ); // main. Display class method } SE-2811 Slide content originally by Dr. Hornick

SE-2811 Dr. Mark L. Hornick 32