Chapter 9 Observer

Chapter 9Observer Summary prepared by Kirk Scott

Design Patterns in JavaChapter 9Observer Summary prepared by Kirk Scott

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

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 • Input might consist of various objects with listeners attached • Output might consist of various panels and their contents

There were also parts of the design where the state of the board and the logic of play were implemented • But this could have been in a higher level class that extended JPanel, for example • In other words, even though the various elements of model, view, and controller were becoming obvious, in the overall design there was no clear distinction about how and where those things should be implemented

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

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

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

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

At the third stage of development of TogizKumalak (the final project for CSCE 202), 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

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

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

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

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

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

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

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 • The examples will illustrate Observer and Model-View-Controller concepts, and how observability is made available in the Java API

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

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 paradigms for how this might be accomplished in code

1. The clients have to regularly check the interesting object for changes • 2. The interesting object notifies clients of changes in its state • When it makes the notification it somehow automatically updates the client based on the changes that have occurred • This would be the most general paradigm

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

The use of listeners as seen so far is representative of the third approach • User actions like clicking the mouse are events • When an event occurs, code is “notified” when the system calls 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 then take certain actions if desired

Observers and Multicasting • Multicasting came up at the end of CSCE 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

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

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

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.

Comment Mode On • Consider a general statement like this: • Good code localizes responsibility so that objects are not dependent on each other • The reality is, that at a cosmic level, when designing and developing a system, by definition you’re creating a set of classes and runtime objects that depend on each other from a problem domain point of view

An application which contains state, has a graphical user interface, and is event driven, necessarily has classes that depend on each other • The observer and MVC design patterns are not about the problem domain • They have been developed as general templates for managing the kinds of dependencies that exist in all kinds of software that GUI’s

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 • The slider is a classic user interface component with a listener

The listener responds to events and changes application state • When state changes, an observer can be notified • The observer can take various actions, including changing the view of the application as a result of the change in the state

This division of labor is the break with your previous experience in creating graphical apps • In your previous efforts, it was highly likely that the listener did two things: • It changed the state and it also updated the graphical view (through repainting, etc.) • Now changes to state and changes to the view will be apportioned to listeners and observers, respectively

Getting Started with the Book’s Example • See the following overhead • The slider is at the bottom • To its left is a label which shows the current value associated with the slider’s position • Above it there are two panels which depend on changes to the slider’s value/position

As will be the case with other examples, the book gives a description of the application domain physics involved in this example • The physics is of no particular interest to us • But we need to understand enough in order to be able to follow the discussion of how the components of the application interact

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 • 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 • tpeakrepresents that point in time in the range from 0 to 1 where the burn rate is at a maximum

Here are the book’s equations for burn rate and thrust • Burn rate is a function of time • Thrust is a function of the burn rate

Controller: The slider in the application allows the user to visually change the value of tpeak, which is part of the state of the application • Model: tpeak is used in the equations for the burn rate and thrust curves • View: Whenever a change is made in tpeak, the panels containing the graphs for burn rate and thrust have to be updated

Observe that by definition, the burn rate graph has a maximum at tpeak • I’m not interested enough in the physics to reason why, but the formula for thrust, mathematically speaking, also gives 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

The folder for this unit includes some example code from the authors • 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 • The mathematical reality of the model is that the shapes of the curves don’t change

The maximums of the two curves merely move to the new position specified by the slider • When you see this, it becomes apparent that you could probably get the same visual behavior through mindless trickery, shifting things from left to right • But the point is to understand how they’re using the pattern, so we will follow through with the mechanics of the example as given

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

Chapter 9 Observer