chap1-1.htm

四人帮《设计模式》一书英文版本

other.  (See <A HREF="pat5dfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5dfs.htm" TARGET="_mainDisplayFrame">Iterator (257)</A>
for an example.)</P>

<A NAME="sec1-2"></A>
<H2><A HREF="#sec1-3"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next: Describing Design Patterns"></A>
Design Patterns in Smalltalk MVC</H2>

<A NAME="auto1017"></A>
<P>The Model/View/Controller (MVC) triad of
classes [<a href="bibfs-1.htm#krasner_mvc" tppabs="http://ultra/development/DesignPatterns/lowres/bibfs.htm#krasner_mvc" target="_mainDisplayFrame">KP88</A>] is used to build user interfaces
in Smalltalk-80.  Looking at the design patterns inside MVC should
help you see what we mean by the term "pattern."</P>

<A NAME="auto1018"></A>
<P>MVC consists of three kinds of objects.  The Model is the application
object, the View is its screen presentation, and the Controller
defines the way the user interface reacts to user input.  Before MVC,
user interface designs tended to lump these objects together.  MVC
decouples them to increase flexibility and reuse.</P>

<A NAME="auto1019"></A>
<P>MVC decouples views and models by establishing a subscribe/notify
protocol between them.  A view must ensure that its appearance
reflects the state of the model.  Whenever the model's data changes,
the model notifies views that depend on it.  In response, each view
gets an opportunity to update itself.  This approach lets you attach
multiple views to a model to provide different presentations.  You can
also create new views for a model without rewriting it.</P>

<A NAME="auto1020"></A>
<P>The following diagram shows a model and three views.  (We've left out
the controllers for simplicity.)  The model contains some data values,
and the views defining a spreadsheet, histogram, and pie chart display
these data in various ways.  The model communicates with its views when
its values change, and the views communicate with the model to access
these values.</P>

<P ALIGN=CENTER><IMG SRC="mvc-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/mvc.gif"></P>

<A NAME="auto1021"></A>
<P>Taken at face value, this example reflects a design that decouples
views from models.  But the design is applicable to a more general
problem: decoupling objects so that changes to one can affect any
number of others without requiring the changed object to know
details of the others. This more general design is described by
the <A HREF="pat5gfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5gfs.htm" TARGET="_mainDisplayFrame">Observer (page 293)</A>
design pattern.</P>

<A NAME="auto1022"></A>
<P>Another feature of MVC is that views can be nested.  For example, a
control panel of buttons might be implemented as a complex view
containing nested button views.  The user interface for an object
inspector can consist of nested views that may be reused in a
debugger. MVC supports nested views with the CompositeView class, a
subclass of View. CompositeView objects act just like View objects; a
composite view can be used wherever a view can be used, but it also
contains and manages nested views.</P>

<A NAME="auto1023"></A>
<P>Again, we could think of this as a design that lets us treat a
composite view just like we treat one of its components.  But the
design is applicable to a more general problem, which occurs whenever
we want to group objects and treat the group like an individual
object.  This more general design is described by the
<A HREF="pat4cfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4cfs.htm" TARGET="_mainDisplayFrame">Composite (163)</A> design pattern. It lets you create a
class hierarchy in which some subclasses define primitive objects
(e.g., Button) and other classes define composite objects
(CompositeView) that assemble the primitives into more complex
objects.</P>

<A NAME="auto1024"></A>
<P>MVC also lets you change the way a view responds to user input without
changing its visual presentation.  You might want to change the way it
responds to the keyboard, for example, or have it use a pop-up menu
instead of command keys.  MVC encapsulates the response mechanism in a
Controller object.  There is a class hierarchy of controllers, making
it easy to create a new controller as a variation on an existing one.</P>

<A NAME="auto1025"></A>
<P>A view uses an instance of a Controller subclass to implement a
particular response strategy; to implement a different strategy,
simply replace the instance with a different kind of controller.  It's
even possible to change a view's controller at run-time to let the
view change the way it responds to user input.  For example, a view
can be disabled so that it doesn't accept input simply by giving it a
controller that ignores input events.</P>

<A NAME="strat-in-mvc"></A>
<P>The View-Controller relationship is an example of the
<A HREF="pat5ifs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5ifs.htm" TARGET="_mainDisplayFrame">Strategy (315)</A> design pattern.  A
Strategy is an object that represents an algorithm.  It's useful
when you want to replace the algorithm either statically or
dynamically, when you have a lot of variants of the algorithm, or
when the algorithm has complex data structures that you want to
encapsulate.</P>

<A NAME="auto1026"></A>
<P>MVC uses other design patterns, such as <A HREF="pat3cfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3cfs.htm" TARGET="_mainDisplayFrame">Factory Method (107)</A> to specify the default controller
class for a view and <A HREF="pat4dfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4dfs.htm" TARGET="_mainDisplayFrame">Decorator (175)</A>
to add scrolling to a view.  But the main relationships in MVC are
given by the Observer, Composite, and Strategy design patterns.</P>

<A NAME="sec1-3"></A>
<H2><A HREF="#sec1-4"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next: The Catalog of Design Patterns"></A>
Describing Design Patterns</H2>

<A NAME="auto1027"></A>
<P>How do we describe design patterns?  Graphical notations, while
important and useful, aren't sufficient. They simply capture the end
product of the design process as relationships between classes and
objects. To reuse the design, we must also record the decisions,
alternatives, and trade-offs that led to it.  Concrete examples are
important too, because they help you see the design in action.</P>

<A NAME="despatt-template"></A>
<P>We describe design patterns using a consistent format.  Each pattern
is divided into sections according to the following template.  The
template lends a uniform structure to the information, making design
patterns easier to learn, compare, and use.</P>

<DL>

<DT><B>Pattern Name and Classification</B>
<DD>The pattern's name conveys the essence of the pattern succinctly.
    A good name is vital, because it will become part of your design
    vocabulary.  The pattern's classification reflects the
    scheme we introduce in
    <A HREF="#sect_catalog_organization">Section 1.5</A>.</DD>

<A NAME="auto1028"></A>
<P></P>

<DT><B>Intent</B>
<DD>A short statement that answers the following questions:
    What does the design pattern do?  What is its rationale and intent?
    What particular design issue or problem does it address?</DD>

<A NAME="auto1029"></A>
<P></P>

<DT><B>Also Known As</B>
<DD>Other well-known names for the pattern, if any.</DD>

<A NAME="auto1030"></A>
<P></P>

<DT><B>Motivation</B>
<DD>A scenario that illustrates a design problem and how the class and
    object structures in the pattern solve the problem.  The scenario
    will help you understand the more abstract description of the
    pattern that follows.</DD>

<A NAME="auto1031"></A>
<P></P>

<DT><B>Applicability</B>
<DD>What are the situations in which the design pattern can be applied?
    What are examples of poor designs that the pattern can address?  How
    can you recognize these situations?</DD>

<A NAME="auto1032"></A>
<P></P>

<A NAME="structure"></A>
<DT><B>Structure</B>
<DD>A graphical representation of the classes in the pattern using a
    notation based on the Object Modeling Technique
    (OMT) [<a href="bibfs-1.htm#rumbaugh_omt" tppabs="http://ultra/development/DesignPatterns/lowres/bibfs.htm#rumbaugh_omt" target="_mainDisplayFrame">RBP+91</A>]. We also use
    interaction diagrams [<a href="bibfs-1.htm#jacobson_oose" tppabs="http://ultra/development/DesignPatterns/lowres/bibfs.htm#jacobson_oose" target="_mainDisplayFrame">JCJO92</A>,
    <a href="bibfs-1.htm#booch_ood" tppabs="http://ultra/development/DesignPatterns/lowres/bibfs.htm#booch_ood" target="_mainDisplayFrame">Boo94</A>] to illustrate sequences of
    requests and collaborations between objects.
    <A HREF="chapBfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/chapBfs.htm" TARGET="_mainDisplayFrame">Appendix&nbsp;B</A> describes these notations
    in detail.</DD>

<A NAME="auto1033"></A>
<P></P>

<DT><B>Participants</B>
<DD>The classes and/or objects participating in the design pattern and
    their responsibilities.</DD>

<A NAME="auto1034"></A>
<P></P>

<DT><B>Collaborations</B>
<DD>How the participants collaborate to carry out their
    responsibilities.</DD>

<A NAME="auto1035"></A>
<P></P>

<DT><B>Consequences</B>
<DD>How does the pattern support its objectives?  What are the
    trade-offs and results of using the pattern?  What aspect of
    system structure does it let you vary independently?</DD>

<A NAME="auto1036"></A>
<P></P>

<DT><B>Implementation</B>
<DD>What pitfalls, hints, or techniques should you be aware of when
    implementing the pattern?  Are there language-specific issues?</DD>

<A NAME="auto1037"></A>
<P></P>

<DT><B>Sample Code</B>
<DD>Code fragments that illustrate how you might implement the pattern
    in C++ or Smalltalk.</DD>

<A NAME="auto1038"></A>
<P></P>

<DT><B>Known Uses</B>
<DD>Examples of the pattern found in real systems. We include at least
    two examples from different domains.</DD>

<A NAME="auto1039"></A>
<P></P>

<DT><B>Related Patterns</B>
<DD>What design patterns are closely related to this one?  What are the
    important differences?  With which other patterns should this one be
    used?</DD>

</DL>

<A NAME="auto1040"></A>
<P>The appendices provide background information that will help you
understand the patterns and the discussions surrounding them.
<A HREF="chapAfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm" TARGET="_mainDisplayFrame">Appendix&nbsp;A</A> is a glossary of terminology we
use.  We've already mentioned
<A HREF="chapBfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/chapBfs.htm" TARGET="_mainDisplayFrame">Appendix&nbsp;B</A>, which
presents the various notations.  We'll also describe aspects of the
notations as we introduce them in the upcoming discussions.  Finally,
<A HREF="chapCfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/chapCfs.htm" TARGET="_mainDisplayFrame">Appendix&nbsp;C</A> contains source code for the
foundation classes we use in code samples.</P>

<A NAME="sec1-4"></A><H2><A HREF="#sec1-5"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next: Organizing the Catalog"></A>
The Catalog of Design Patterns</H2>