Java Reference
In-Depth Information
The
model
that stores the data that defines the component.
❑
The
view
that creates the visual representation of the component from the data in the model.
❑
The
controller
that deals with user interaction with the component and modifies the model
and/or the view in response to a user action as necessary.
❑
model
acts on
acts on
controller
view
acts on
In object-oriented terms, each of the three logical parts for a component - the model, the view, and the
controller - is ideally represented by a different class type. In practice this turns out to be difficult
because of the dependencies between the view and the controller. Since the user interacts with the
physical representation of the component, the controller operation is highly dependent on the
implementation of the view. For this reason, the view and controller are typically represented by a
single composite object that corresponds to a view with an integrated controller. In this case the MVC
concept degenerates into the document/view architecture that we introduced when we discussed the
Observable
class and
Observer
interface. Sun call it the
Separable Model architecture
.
UI Manager
(feeds look-and-feel to component)
View
(The look of the component)
Model
(Component Data)
Controller
(deals with events making
changes to the model or view)
UI Delegate
Component
Separable Model Architecture
The way the Swing components provide for a pluggable look-and-feel is to make the visual appearance
of a component and the interface to the user the responsibility of an independent object called the
UI
delegate
. This is the view+controller part of the MVC model. Thus a different UI delegate can provide
a component with a new look-and-feel.
