Compellingly Beautiful Software
Products Programming Contact
Steven T Abell, Software Designer, brising.com
You don't.
Many software textbooks and articles mention the Model-View-Controller
(MVC) UI architecture that originated in the Smalltalk programming language.
Some of these claim to tell you what MVC means and how to build it. But,
unless the book or article is explicitly about Smalltalk, and in some cases
even if it is, what you're reading about probably isn't MVC.
MVC is an important milestone in object programming. It deals with three
important abstract notions about objects: factoring, patterns, and
frameworks.
Factoring means breaking your design into separate pieces, each of
which is highly focused on some simpler thing or process, then reassembling
the larger functionality from the smaller pieces. Good factoring can have
several nice results, such as code reuse and improved maintainability.
Patterns are arrangements of objects that have the same general
connective shape and channels of message flow. Knowledge of patterns can
help you solve new problems in familiar ways. Even if you can't reuse existing
code, you'll at least know how to go about what you're building.
When you factor a problem well, and then discover that you're building
that same pattern over and over, sometimes you can build a framework,
which is a partially-complete arrangement of objects. Frameworks help you
get to the end of the job because you're starting from the middle of the
job instead of from the beginning.
In Smalltalk, MVC became a framework and acquired many admirers, many of
whom didn't really understand it. MVC breaks UI architecture into three
pieces: Model, View, and Controller.
A Model is an object that (usually) holds data and (often) simulates
a process. Properly-designed Models try not to make assumptions about how
they will be displayed. They live in the dark depths of a computer, relying
on other objects to expose them to a user. Although they don't contain any
UI components, they often notify these components of internal changes in a
very general way. In Java, these notification mechanisms are provided in classes
such as Observable and PropertyChangeSupport, although I have to say that
the implementation and performance of these particular foundation classes
is execrable.
A View is an output device. Please reread the previous sentence
until you understand just how definite and general that statement is. In
the Graphical User Interfaces that have become so common, a View is usually
thought of more specifically as a screen widget, such as a textfield.
A Controller is an input translator. Please reread the previous
sentence until you understand just how definite and general that statement
is. In today's GUIs, they are usually thought of more specifically as mouse
and keyboard drivers.
Most widget kits, for example, AWT and Swing in Java, or Qt and the Microsoft
widgets in C++, conflate the View and Controller into a single object. This
is not really wrong, but it does limit some of the options in GUI construction.
Because few people have ever seen true MVC, where Vs
and Cs are created separately and then hooked together, few people understand
the loss in VC conflation, but they still like to talk about MVC and how
great it is. Maybe it makes them feel cool.
In the remainder of this article, a conflated View-Controller pair is
referred to as a ViewControl.
So what do people mean when they talk about MVC? Good question, whose answer
is sometimes "Your guess is as good as mine." When some people talk
about a Controller, what they mean would be a very reasonable use of the
word if the word was not already used elsewhere. This other object (the
reasonable one) coordinates the interactions of the Model and one
or more ViewControls. Various people have come up with various names for
this object other than Controller. This is a good idea. I call it a Coordinator.
Look over the alternatives you find in the literature, and by the end of
the day I'll bet you'll call it a Coordinator, too.
How can you tell a Model-View-Controller from a Model-Coordinator-ViewControl?
An MVC diagram is a triangle; an MCV diagram is linear (the degenerate case)
or Y-shaped (the more general case, with possibly many branches in the Y).
In MCV, the Coordinator sits between a Model and one or more ViewControls.
The nature of the interactions is very different.
So if you read about MVC in the Swing documentation or some article on
Java, let me suggest that you not take it very seriously. Swing is a decent-but-not-great
piece of work, and it is not at all clear that its designers understood
MVC very well. And if some professor gives you an assignment to build an
MVC application in Java, you might send him an anonymous email suggesting
that he read this page first. True MVC is out of reach for Java programmers
who are building with the standard Swing or AWT widgets.
© 2002 brising.com