Unit 30 Observer

1. Unit 30Observer Summary prepared by Kirk Scott

9. Design Patterns in JavaChapter 9Observer Summary prepared by Kirk Scott

10. The Introduction Before the Introduction • Think back to Wari and TogizKumalak • The very first implementations weren’t graphical at all • The second stage of implementation grew into hand-coded cups represented by rectangles, containing seeds represented by dots • At this stage, mouse functionality was introduced so that game play was conducted by clicking the mouse

11. The state of the code at the second stage illustrated several things • Thinking back to the UML diagrams, they tended to branch in two directions, an input side and an output side • Thus, the input and output were relatively distinct, but the game itself, that is to say, the state of the board and logic of play was mixed up with the input and output stuff

12. Taking Wari as an example, this is the Model-View-Controller idea: • The model part would be the board, the rules of play, and the state of the game • The view part would be the output side of the application • The controller part would be the input side of the application

13. The logic of the Model-View-Controller pattern is to cleanly separate these functionalities into different classes • Although there was some separation in the Wari examples, they didn’t have a pure model-view-controller design

14. At the second stage of the development of Wari, on the output side you had graphical representations of hand-coded graphical objects • The key result of this fact is that when the state of the game changed, it was necessary to call repaint() in order to update the on-screen representation

15. This introduced the idea of a callback sequence • In other words, you had to write a paintComponent() method, but you never called it directly • You relied on the system to perform a callback sequence when you called repaint

16. At the third stage of development of TogizKumalak (the project), the implementation was changed so that all of the graphical representations were done with system supplied objects • In other words, the application consisted of a panel containing instances of JButton, JTextField, JLabel, and JTextArea

17. This made life considerably easier because whenever the state changed, there was no need to call repaint() • The system took care of this automatically

18. Stated simplistically • At stage 2, TogizKumalak was 50% system supplied magic, based on the callback sequence • At stage 3, TogizKumalak was 100% system supplied magic

19. If you got the final project to work, then empirically its design was OK • But you basically flailed your way towards a nice implementation, trying to follow examples without necessarily having a good conceptual grasp of what you were doing

20. Where We’re Headed • In Wari, on the input side you had listeners • It turns out that the concept of “listening” is critical to the use of the Observer and Model-View-Controller patterns • Listeners detect and react to events • It turns out that you can also have observers, which can be notified of changes in the state of objects

21. Having listeners on the input side and observers on the output side allows for complete separation of the different parts of a design • The idea is that in your own code, you can write classes that have the ability to be notified of events occurring with objects of other classes

22. Java contains an interface named Observer and a class named Observable • These are the constructs which support observability

23. What the Book Covers • The book develops a sequence of examples based on Oozinoz • As usual, I’m not interested in the physics content of their code • These will illustrate Observer and Model-View-Controller concepts, and how observability is made available in the Java API

24. The book’s presentation starts with the basic concept, the Observer pattern, and moves to the Model-View-Controller pattern • The book tries to illustrate the concept step-by-step • It starts with a first version of the code, moves on to a second, and then arrives at a third, final version

25. The book explains the observer concept using the terminology of clients and what it calls “an interesting object” • The idea is that the clients are objects that need to keep up to date on the state of the interesting object • There are basically three different models for how this might be accomplished in code

26. 1. The clients have to regularly check the interesting object for changes • 2. The interesting object notifies clients of changes in its state where the notification includes information about the new state

27. 3. The interesting object notifies clients that its state has changed, but the notification does not contain information about the new state • In that case, it is up to the clients to take action (if desired) to acquire the information and do something about it

28. Notice how the third approach matches up with the use of listeners as seen so far • User actions like clicking the mouse are events • The system activates a call to a listener and passes it the event • The method in the listener, like actionPerformed(), can call methods on the event object to find out more about it if desired • The listener code can take certain actions if desired

29. Observers and Multicasting • Multicasting came up at the end of CS 202 • In the example code given in unit 28, there was a single “clear” button and several different registers represented by instances of JTextField • Each register had its own listener that was notified if the clear button was clicked • The action each register took was to clear its JTextField when the clear button was clicked

30. Up to that point, the plan had appeared to be one actionone listener • Then it became one actionmany listeners • Using the observer terminology of the book, the situation became one interesting objectmany clients

31. It now becomes possible to lay the groundwork for the book’s statement of the intent of the Observer design pattern • We are interested in a situation where you have one interesting object and potentially many client objects • The book describes this as a dependency relationship, where the clients depend on being notified of the state of the interesting object

32. Book Definition of the Pattern • Book definition: The intent of the Observer pattern is to define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified so that they can react to the change.

33. A Classic Example: Observer in GUIs • Listeners are the classic example of dependent clients that are notified when an event occurs • It will turn out that observing is analogous to listening • The book is going to develop an example which uses a slider control which responds to events and changes application state • Observers will then respond to the changes in state

34. See the following overhead • The slider is at the bottom • To its left is a label which shows its current value • Above it there are two panels which depend on changes to it

36. The book, as usual, gives a description of the application domain physics involved in the example • In brief, when a solid rocket motor burns, the burn rate of the rocket changes over time, and the thrust it delivers changes over time as a function of the burn rate • The situation is partially analogous to the previous example where parametric equations were used

37. Burn rate is expressed as a function of time, t • It is convenient both mathematically and for the sake of graphing to normalize t to the range from 0 to 1 • Thrust is expressed directly as a function of the burn rate • The new addition to the scenario is a parameter tpeak

38. Here are the book’s equations for rate and thrust • tpeak will be explained on the following overheads

39. tpeak represents that point in time in the range from 0 to 1 where the burn rate is at a maximum • The slider allows the user to change the value of tpeak entered into the graphing equations • Whenever a change is made, the panels containing the graphs for burn rate and thrust have to be updated

40. Observe that by definition, the burn rate graph has a maximum at tpeak • I’m not interested enough in the math and physics to figure it out, but it certainly seems like the thrust graph should and does have a maximum at the same point in time • As the slider is moved, the graphs should change, with the maximums appearing at the new value for tpeak

41. If you go out to the assignment folder for this chapter, the third version of the authors’ code is given, unpackaged and with one slight coding change so that it will run in TextPad • If you run it, you will notice that the real effect of moving the slider is that the positions of the burn rate and thrust curves shift in their panels

42. The mathematical reality of the model is that the shapes of the curves don’t change • Their maximums merely move to the new position specified by the slider

43. The First Example • As mentioned, the book develops a design for the application in three stages, moving towards a full-scale model-view-controller implementation • On the next overhead is the UML diagram for the first design • This design works • The book explains it, and then uses its shortcomings as a starting point for the next design

45. The contents of the first design can be verbally summarized as follows • At the top left there is a listener interface, ChangeListener, with a method stateChanged() with a parameter of type ChangeEvent • At the lower left is the ShowBallistics class which implements this interface, which will be discussed in more detail momentarily

46. On the right hand side is the BallisticsPanel class • It is a subclass of the JPanel class • It makes use of the BallisticsFunction interface

47. The application here is again structured in a manner similar to the parametric equations example • When a BallisticsPanel object is created, it is given an instance of a function which represents the graph it is supposed to show • The BallisticsPanel class has a setTPeak(tPeak:double) method that parameterizes the function to be shown

48. The ShowBallistics class is the heart of the design • Although its contents are not very complex, the variety of things in the class may hint at problems with the design • The ShowBalllistics class contains two instances of the BallisticsPanel class • There is one panel each for the burn rate and the thrust graphs

49. The ShowBallistics class contains four methods • burnPanel() returns a reference to an instance of BallisticsPanel • thrustPanel() returns a reference to an instance of BallisticsPanel

50. slider() returns a reference to an instance of JSlider • valueLabel() returns the numeric value of tpeak that the slider has been moved to • stateChanged(e:ChangeEvent) implements the method required by the interface ChangeListener