In general, a visual component
is a composite of three distinct aspects:
The way that the component looks when rendered on the screen
The way that the component reacts to the user
The state information associated with the component
No matter what architecture
is used to implement a component, it must implicitly contain these three parts.
Over the years, one component architecture has proven itself to be
exceptionally effective: Model-View-Controller,
or MVC for short.
The MVC architecture is
successful because each piece of the design corresponds to an aspect of a
component. In MVC terminology, the model
corresponds to the state information associated with the component. For
example, in the case of a check box, the model contains a field that indicates
if the box is checked or unchecked. The view
determines how the component is displayed on the screen, including any aspects
of the view that are affected by the current state of the model. The controller determines how the component
reacts to the user. For example, when the user clicks a check box, the
controller reacts by changing the model to reflect the user’s choice (checked
or unchecked). This then results in the view being updated. By separating a
component into a model, a view, and a controller, the specific implementation
of each can be changed without affecting the other two. For instance, different
view implementations can render the same component in different ways without
affecting the model or the controller.
Although the MVC architecture
and the principles behind it are conceptually sound, the high level of
separation between the view and the controller is not beneficial for Swing
components. Instead, Swing uses a modified version of MVC that combines the
view and the controller into a single logical entity called the UI delegate. For this reason, Swing’s
approach is called either the Model-Delegate
architecture or the Separable Model
architecture. Therefore, although Swing’s component architecture is based on MVC,
it does not use a classical implementation of it.
Swing’s pluggable look and
feel is made possible by its Model-Delegate architecture. Because the view
(look) and controller (feel) are separate from the model, the look and feel can
be changed without affecting how the component is used within a program.
Conversely, it is possible to
customize the model without affecting the way that the component appears on the
screen or responds to user input.
To support the Model-Delegate
architecture, most Swing components contain two objects. The first represents
the model. The second represents the UI delegate. Models are defined by
interfaces. For example, the model for a button is defined by the ButtonModel interface. UI delegates are
classes that inherit ComponentUI.
For example, the UI delegate for a button is ButtonUI. Normally, your programs will not interact directly with
the UI delegate.