Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Dept. of Computer Science & Engineering, York University, Toronto CSE3311 – Software Development Observer Pattern.

Similar presentations


Presentation on theme: "1 Dept. of Computer Science & Engineering, York University, Toronto CSE3311 – Software Development Observer Pattern."— Presentation transcript:

1 1 Dept. of Computer Science & Engineering, York University, Toronto CSE3311 – Software Development Observer Pattern

2 2 Weather-O-Rama Inc Statement of Work  Congratulations on being selected to build our next generation of internet based weather monitoring station.  Details follow below.  We look forward to seeing your design by tomorrow night! Sincerely John Hurricane CEO P.S. We are overnighting the WEATHER_DATA source files to you

3 3 Weather-O-Rama Hardware provided by Weather-O-Rama Class WEATHER_DATA must satisfy a specified interface so that the Weather Station can signal a change. It then updates its displays for current conditions, statistics etc. What must we implement? Create an app that updates the various displays real-time Current Conditions Temp: 73F Humidity: 60 Pressure:  Statistics Avg. Temp: 62F Min. Temp: 50F Max. Temp: 78F … other views …..

4 4

5 5 deferred class WEATHER_DATA feature -- weather data available to observers temperature: REAL humidity: REAL pressure: REAL correct_limits (t, p, h: REAL_32): BOOLEAN ensure Result implies -36 <= t and t <= oC Result implies 50 <= p and p <= KPa Result implies 0.8 <= h and h <= %RH measurements_changed -- called from weather station after a set_measurement set_measurements (t, p, h: REAL_32) -- called from weather station require correct_limits (t, p, h) invariant correct_limits (temperature, pressure, humidity) end We are provided with Must complete this code

6 6  We are provided with class WEATHER_DATA  But this class is closed for business

7 7 First Design class WEATHER_DATA_IMP inherit WEATHER_DATA feature current_conditions: CURRENT_CONDITIONS statistics: STATISTICS forecast: FORECAST... measurements_changed do current_conditions.update(temp, humidity, pressure) end Nice common “update” interface Problems? Use Inheritance Open Closed Principle

8 8 Problems?  Is update coded to concrete implementation, or to interfaces?  Do we need to add code to the class for each new display?  Can we add/remove new displays from a client at runtime?  Have we encapsulated that which changes? Part that changes

9 9 Observer: ONE  MANY relationship Observers: Current Conditions Display Forecast Display Statistics Display Subject Weather Data automatic update

10 10 Observer Pattern  Intent  Define one-to-many dependency  When one subject changes state, all observers are notified and correspondingly updated  Also known as  Publish-Subscribe

11 11 Observer – Motivation A is 30% B is 50% C is 20% text view Observers Notify change Request modification rectangle viewbar viewtarget view

12 12 Observer Architecture – Example OBSERVER * update * SUBJECT attach(observer) detach(observer) notify TEXT_VIEW get_state set_state BAR_VIEW + update + observers : set[…] update * subject TARGET_VIEW + update + RECTANGLE_VIEW + update + subject

13 13 Observer – Abstract Architecture update * SUBJECT attach(observer) detach(observer) notify CONCRETE_SUBJECT get_state set_state CONCRETE_OBSERVER + update + observers : LIST[…] OBSERVER * update * subject  o:observers o.update subject.get_state Current.notify

14 14 Observer – Scenario  Concrete subject updates all observers, when state is changed by a client 1 set_state 2 notify 3 update 4 get_state Scenario: Update observers CLIENT CONCRETE_SUBJECT 1 3 CONCRETE_OBSERVER 4 2

15 15 UML

16 16 deferred class OBSERVER feature -- to be effected by a descendant update -- update the observer's view of the subject deferred ensure up_to_date_with_subject end up_to_date_with_subject: BOOLEAN -- is this observer up to date with its subject deferred end OBSERVER * update * How can we ensure that the update worked?

17 17 class SUBJECT create make feature -- invoked by a SUBJECT observers: LIST [OBSERVER] -- list of observers attached to this subject attach (o: OBSERVER) require o /= Void and not observers.has(o) ensure observers.has(o) detach (o: OBSERVER) … notify … SUBJECT attach(observer) detach(observer) notify

18 18 class SUBJECT feature … observers: LIST [OBSERVER] … attach (o: OBSERVER) … detach (o: OBSERVER) … notify -- Send an `update' message to each observer o do from observers.start until observers.after loop observers.item.update; observers.forth end ensure observers.for_all (agent (o: OBSERVER): BOOLEAN do Result = o.up_to_date_with_subject end) invariant observers_not_void: observers /= Void end SUBJECT attach(observer) detach(observer) notify

19 19 back to Weather-O-Rama  Ok, so what classes will we need?  Sketch a BON diagram

20 20 back to Weather-O-Rama  WEATHER_DATA is closed; so inherit from it  How to use the observer pattern? Multiple inheritance Is-a WEATHER_DATA Is-a SUBJECT

21 21 Effect measurements changed via notify Inherit subject behaviour such as add an observer (display) notify all observers Inherit weather data behaviour such as temp, pressure, humidity

22 22 What about the displays

23 23 Displays

24 24 class CURRENT_CONDITIONS inherit OBSERVER create make feature {NONE} -- initialize make (wds: WEATHER_DATA_SUBJECT) do weather_data := wds weather_data.attach (Current) end feature weather_data: WEATHER_DATA_SUBJECT -- subject temperature: REAL_32 humidity: REAL_32 update -- update the observer's view of subject do temperature := weather_data.temperature humidity := weather_data.humidity display end... end Attach the current display to the weather data subject

25 25 class CURRENT_CONDITIONS inherit OBSERVER create make feature {NONE} -- initialize make (a_weather_data: WEATHER_DATA_SUBJECT)... feature weather_data: WEATHER_DATA_SUBJECT -- subject temperature: REAL_32 humidity: REAL_32 update... up_to_date_with_subject: BOOLEAN -- is this observer up to date with its subject do if temperature = weather_data.temperature and humidity = weather_data.humidity then end display... end It is easy to forget to synch A contract failure will remind you, if you forget to do this

26 26 Power up weather station class WEATHER_STATION create make feature cc: CURRENT_CONDITIONS -- displays fd: FORECAST sd: STATISTICS wd: WEATHER_DATA_SUBJECT make do create wd.make create cc.make (wd); create fd.make (wd); create sd.make (wd) wd.set_measurements (15, 60, 30.4); wd.measurements_changed wd.set_measurements (19, 56, 20); wd.measurements_changed wd.set_measurements (11, 90, 20); wd.measurements_changed end

27 27

28 28 Design Principle: Strive for loosely coupled designs between objects that interact. OOSC2: Chapter 3 on modularity Direct mapping principle Few interfaces principle (a module should communicate with as few others as possible) Small interfaces principle (exchange as little information as possible) Explicit interface principle (interface obvious from the text) Information hiding Self documentation principle limited bandwidth

29 29  Loosely coupled designs allow us to build flexible OO systems that can handle change because they minimize the dependency between objects Design Principle: Strive for loosely coupled designs between objects that interact.

30 30 Add a new display for the heat index?

31 31 Java’s built-in pattern (e.g. in Swing) Cannot use MI

32 32

33 33 MVC iTunes mp3 player

34 34

35 35

36 36 CGI: Dynamic Pages Client Web Server File Server HTTP NFS CGI App Server JDBC DB Server By: Prof. H. Roumani Eiffel CGI/sqlite3 webapp class WEB_APP inherit CGI SQLITABLE...

37 37 HR/37 Key Characteristics of CGI 1.Browser sends an HTTP request to the Web Server 2.Web Server identifies the request as CGI 3.Web Server dispatches the request to the App Server 4.App Server impersonates the script’s owner 5.App Server runs the script passing the request 6.Script outputs the response to Standard Output 7.App Server routes Standard Output to the Web Server 8.Web Server returns the response to the browser

38 38

39 39

40 40 Google: “Gang of Four”


Download ppt "1 Dept. of Computer Science & Engineering, York University, Toronto CSE3311 – Software Development Observer Pattern."

Similar presentations


Ads by Google