The Observer Design Pattern

Transcription

1 The Observer Design Pattern Some common applications Responding to GUI events Responding to changes in data values Model The observing task registers to be notified on any change of state for the object of interest Once notified it is the observer s responsibility to respond as appropriate This approach encourages loosely coupled design In the GoF classification this is a behavioral design pattern

2 Acknowledgements Materials were borrowed from Design Patterns in Java by Steven Metsker and William Wake (textbook for course) Design Patterns Explained by Alan Shalloway and James R. Trott Head First Design Patterns by Elisabeth Freeman, Eric Freeman, Bert Bates, and Kathy Sierra

3 Responding to GUI Events As a user manipulates a GUI many program components may need to respond Here a slider is adjusted by the user; the graphs for Burn Rate and Thrust need to be changed in real time The slider for tpeak ranges from time 0 at ignition and time 1 when burning fuel is exhausted

4 Responding to Slider Changes The ballistics application initializes the slider and registers to be notified of changes ShowBallistics changes the burnpanel, thrustpanel, and valuelabel based on the slider value This is a poor design since a single object takes complete responsibility

5

6 Solution 9.1

7 Have Individual Objects Respond Rethinking the design Currently a single object, ShowBallistics, takes complete responsibility for making changes to other objects It would improve the design in each individual object was notified of changes in the slider value and changed itself accordingly

8 Solution 9.2

9 Changes in the Code The addchangelistener() method is moved out of the slider() method and into each interested component Similar changes are made to BallisticLabel2.

10

11

12

13 Calculating Tpeak Other Design Weaknesses Each component listening to the sliders needs to recalculate Tpeak This results in duplicate code in the statechanged method in the BallisticPanel2 and BallisticLabel2 classes We can refactor yet again Create a Tpeak object that listens to changes in the slider After each change a new Tpeak value is calculated Now have BallisticPanel2 and BallisticLabel2 register to listen for changes in the Tpeak value We are now using a Model, View, Controller (MVC) design The new Tpeak object is part of the underlying model Some computer scientists call MVC a design pattern, but it actually combines several design patterns together

14 Model/View/Controller Subsystems are classified into 3 different types Model subsystem: Responsible for application domain knowledge View subsystem: Responsible for displaying application domain objects to the user Controller subsystem: Responsible for sequence of interactions with the user and notifying views of changes in the model. Controller initiator * 1 Model repository View subscriber * 1 notifier

15 Introducing a Tpeak Class

16 Layering the Design Each layer has a similar set of responsibilities Here we show a GUI layer and a business layer that contains the system model The java API support this design with an Observable class and an Observer interface; here is the code for setvalue

17 Implementing the Observer Interface BalisticsLabel and BalisticsPanel implement Observer They are required to implement the update() method They do not need to maintain a reference to the Tpeak object since the first parameter to update will reference this object In the case of the label, it will cast the object to Tpeak, extract the new value, change the labels text field, and call repaint

18 The BallisticsLabel Object

19 Separating the GUI Elements and Business objects Other Changes The Tpeak object must observe changes in the slider and recalculate its value You can do this by instantiating an anonymous subclass of change listener

20 This is an anonymous (unnamed) object

21 Solution 9.5

22

23 Solution 9.6

24 Alternative Approaches Limitations of subclassing Observer In the approach shown Tpeak is a subclass of Observable Due to the limitation to single inheritance in Java, this may not be possible if Tpeak is already subclassed in the application domain Using PropertyChangeSupport The Component class in java.awt uses a PropertyChangeSupport object (this is from the JavaBeans API) to let interested observers register to be notified of changes in GUI objects Many methods in PropertyChangeSupport are the same as methods in Component

25 Relationship Between Component, PropertyChangeSupport, and PropertyChangeListener

26

27 Solution 9.7

28 Implementing your own Observers Java provides two alternative mechanisms Having the subject extend the Observable class and the observers implement the Observer interface Using the PropertyChangeSupport java bean You can also implement your own observer mechanism Shalloway and Trott in their book Design Patterns Explained provide a detailed example If you do your own observer, you have more control on how the mechanism is implemented and whether it uses a push or pull approach (see next slide)

29 The Push and Pull Approach How much detail is provided when the object of interest is changed? The push approach The observed object details what happened The notification can provide the old and new values The pull approach The observed object only tells the observers that it changed The observers query the object to find the details The appropriate design choice depends largely on the application; the push approach requires more work and increases coupling, but may have better performance