Distributed computing – the client - JavaTech: An Introduction to Scientific and Technical Computing with Java - page 493

polling thread does not attempt to modify the data while the data-display thread is
using it.
As mentioned in the previous chapter, some decisions must be made regarding
how to deal with the relative speeds of the client and server machines and the
network between them. That is, should the SimData object in Chapter 16 store
all simulation data until retrieved by the client or discard old data if new data
arrives before the client has requested it? Or perhaps the client should attempt to
retrieve data as fast as possible and store that data on the client side. As before,
the details are not important to a general discussion but become very important
when an implementation is begun. For simplicity, we assume that the client and
the network are fast enough to collect the data from the server as often as needed.
This assumption essentially means that if the server calculates data faster than
the client's polling thread retrieves it, then SimData merely discards the old data
and always returns the most recently calculated simulation data to the client.
17.3 Model-View-Controller for the client
Recall from the general discussion in Chapter 16 that we desire a way for the
user to control the simulation in some fashion. We explain how the control data is
collected and used in more detail below. For now, consider that we have a server
generating data to be displayed, a client displaying that data, and some means for
the user to control the simulation. This arrangement leads quite naturally to the
Model-View-Controller design pattern for the client, this time a more obvious
application of MVC. The client's graphical display of the data is clearly the view,
and the control data portion of the user interface is the controller. The server is
obviously the data model. From a client-design point of view, it is better to view
the client-side object that fetches data from the server as the data model. How it
generates the data (which happens to be by contacting the server) is immaterial
to the client design.
The Java class library conveniently provides the java.util.Observable
class and the related java.util.Observer interface as perfect aids for imple-
menting the data and view components, respectively, of the MVC design pattern.
By extending Observable ,weobtain a class that our client application wants to
have observed. This technique provides a perfect data model since data can reside
in the Observable subclass, and the view component is the observer of that data.
When the data contained in the Observable changes, the view component can
be notified to update the view. In practice, there can be more than one view com-
ponent. For example, we may wish to display the data in multiple ways - tables
of numbers, graphs of different types, etc. Each type of display is a part of the
MVC view but will be implemented as a different view object. The most straight-
forward way to implement these view objects is to create classes that implement
the Observer interface, which requires that the update() method be imple-
mented. When the Observable obtains new data, the Observer objects are