Example -- the MVC paradigm
A significant part of the effort of system development
often goes into the design and implementation of
the user interface.
The general feeling with respect to user interface components
is that these clutter up the design.
Nevertheless, as the example of the automated teller machine shows,
interaction with the user may be an intrinsic
part of the system.
In [BC89], the CRC cards method has also been used
to characterize the so-called Model-View-Controller
paradigm,
which has become popular as
an architectural device for developing
user interfaces.
The MVC paradigm allows us to develop a user
interface in a non-intrusive manner,
that is without cluttering the application code.
The idea is to provide standard (base) classes
from which application-specific classes, that
implement the particular details, may be derived.
See slide [3-mvc].
Model, View & Control -- user interface design paradigm
slide: The Model-View-Controller paradigm
The class derived from the Model class
is intended to maintain the problem-related
information.
The only thing a model object needs to do
is notify the other (dependent) objects when
some of the information it carries has changed.
In response to being notified of a change, the
view object (an instance of
the class which is derived from View)
may request what it needs to know to
refresh the display of the contents
of the model object.
A controller object is employed to interact
with the user.
Any relevant input is transferred to the model object,
that may in its turn notify the view object
of a change.
For the automated teller machine, the account class
will be the obvious choice for being derived from
the Model class.
Clearly, the card-reader class will have
Controller as its base class and the screen class
will be derived from View.
An important advantage of using the MVC-paradigm
is that it allows the programmer to
separate the problem-related code from
the code needed to implement the (often intricate)
details of interacting with the various input and
output devices.
Another advantage lies in the flexibility of the approach.
One model object may be associated with
arbitrary many different view-controller pairs,
simply by adding another view object to the
list of dependent objects that will be notified of
a change.
Since each view class specifies what it needs
to know of the model, the model class
itself will remain unaffected.
Although the MVC-paradigm was
introduced in the Smalltalk-80 environment,
similar interaction protocols have been used
in user interface libraries for C++, for example
the Interviews library (see Linton {\it et al.}, 1989).
See also sections [cooperation] and [libraries].
From the perspective of design, the paradigm is
attractive since it may be applied in a cookbook
fashion to implement intricate user interfaces,
often simply by reusing available code.
See [KP88] for a number of example recipes.
In section [cooperation] we will further explore
the interaction protocol underlying the
MVC-paradigm.