Smalltalk and Object Orientation: an Introduction - Free

• reusability of application and / or user interface components,
• ability to develop the application and user interface separately,
• ability to inherit from different parts of the class hierarchy.
In fact, in the MVC, the user interface is further subdivided into the output (to the screen) part and
the input (from the user) part. This enables different output elements (look) to be connected with
different input elements (feel). Each part of the MVC therefore attempts to provide the functionality
required by one of these three areas.
26.2.1 The structure of the MVC
The MVC is actually made up of three cooperating components. T hese three components are known as
the Model, the View and the Controller. These three components are illustrated in Figure 26.2 and are
collectively known as the MVC triad.
Model View Controller
Data Display Menu
Cut
Paste
Copy
Save
Figure 26.2: The use of the MVC
This division of responsibility in the MVC is broken down in the following way:
• Model - The information model which handles data storage and informatio n processing. That is,
it manages the behaviour of the data in the application domain.
• View - Which handles the visual display (the output part). That is, it handles how the
information about the application is displayed on the screen.
• Controller - This provides the user interaction to, or control of, the information models
processing (the input part). That is, it handles the mouse and keyboard inputs.
The diagram in Figure 26.2 illustrates the idea behind each aspect of the MVC. To use the MVC
architecture you must understand the division of labor within the MVC triad. However, you should be
aware that in real applications, this division of labor is not always as clean as it should be. Fo r example,
controller like behaviour can leak into the view object, while view like behaviour can leak into the
controller object!
In addition, you must also understand how the three elements communicate (even if you are using
one of the window building to ols). Of course in any application there are many objects which aren’t
models (or which are contained within the model but don’t realize that they are part of a model or a
graphical system). However, they invariably work with the model to provide the overall application.
26.2.2 The elements in the MVC triad
26.2.2.1 Models
As has already been stated a model handles data storage and information processing. That is, it handles
how the application data is processed (i.e. the functionality of the system). That means that model s are
responsible for holding data, operating on that data and responding to requests for information.
Essentially, they are exactly what you have already been looking at throughout this book: “they are one
or more objects which provide some set of operati ons”. For example, the Statement class in the
financial manager application, which you have encountered a number of times in this book, could be
considered to be a model. It held information on deposits and withdrawals. It responded to new deposits
214