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.