chap1.htm

设计模式英文版 作者：Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides 四人帮的书。 学设计模式的必读的书籍！经典中的经典

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.htm" TARGET="_mainDisplayFrame">Composite&nbsp;(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.htm" TARGET="_mainDisplayFrame">Strategy&nbsp;(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.htm" TARGET="_mainDisplayFrame">Factory Method&nbsp;(107)</A> to specify the default controller
class for a view and <A HREF="pat4dfs.htm" TARGET="_mainDisplayFrame">Decorator&nbsp;(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="gifsb/down3.gif" BORDER=0></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&nbsp;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)&nbsp;[<A HREF="vfs.htm?doc=bib-0.htm&fid=bb&hid=rumbaugh_omt" TARGET="_mainDisplayFrame">RBP+91</A>]. We also use
    interaction diagrams&nbsp;[<A HREF="vfs.htm?doc=bib-0.htm&fid=bb&hid=jacobson_oose" TARGET="_mainDisplayFrame">JCJO92</A>,
    <A HREF="vfs.htm?doc=bib-0.htm&fid=bb&hid=booch_ood" TARGET="_mainDisplayFrame">Boo94</A>] to illustrate sequences of
    requests and collaborations between objects.
    <A HREF="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.htm" TARGET="_mainDisplayFrame">Appendix&nbsp;A</A> is a glossary of terminology we
use.  We've already mentioned
<A HREF="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.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="gifsb/down3.gif" BORDER=0></A>
The Catalog of Design Patterns</H2>

<A NAME="auto1041"></A>
<P>The catalog beginning on <A HREF="patcafs.htm" TARGET="_mainDisplayFrame">page 79</A>
contains 23 design patterns.  Their names and intents are listed next
to give you an overview.  The number in parentheses after each pattern
name gives the page number for the pattern (a convention we follow
throughout the book).</P>

<A NAME="intro_intents"></A>

<DL>

<A NAME="absfact"></A>
<DT><B><A HREF="pat3afs.htm" TARGET="_mainDisplayFrame">Abstract Factory&nbsp;(87)</A></B>
<DD>Provide an interface for creating families of related or dependent
objects without specifying their concrete classes.

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

<A NAME="adapter"></A>
<DT><B><A HREF="pat4afs.htm" TARGET="_mainDisplayFrame">Adapter&nbsp;(139)</A></B>
<DD>Convert the interface of a class into another interface clients
expect.  Adapter lets classes work together that couldn't otherwise
because of incompatible interfaces.

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

<DT><B><A HREF="pat4bfs.htm" TARGET="_mainDisplayFrame">Bridge&nbsp;(151)</A></B>
<DD>Decouple an abstraction from its implementation so that the two
can vary independently.

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

<DT><B><A HREF="pat3bfs.htm" TARGET="_mainDisplayFrame">Builder&nbsp;(97)</A></B>
<DD>Separate the construction of a complex object from its representation
so that the same construction process can create different
representations.

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

<DT><B><A HREF="pat5afs.htm" TARGET="_mainDisplayFrame">Chain of Responsibility&nbsp;(223)</A></B>
<DD>Avoid coupling the sender of a request to its receiver by giving more
than one object a chance to handle the request.  Chain the receiving
objects and pass the request along the chain until an object
handles it.

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

<DT><B><A HREF="pat5bfs.htm" TARGET="_mainDisplayFrame">Command&nbsp;(233)</A></B>
<DD>Encapsulate a request as an object, thereby letting you parameterize
clients with different requests, queue or log requests, and support
undoable operations.

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

<DT><B><A HREF="pat4cfs.htm" TARGET="_mainDisplayFrame">Composite&nbsp;(163)</A></B>
<DD>Compose objects into tree structures to represent part-whole
hierarchies.  Composite lets clients treat individual objects and
compositions of objects uniformly.

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

<A NAME="cat-dec"></A>
<DT><B><A HREF="pat4dfs.htm" TARGET="_mainDisplayFrame">Decorator&nbsp;(175)</A></B>
<DD>Attach additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to subclassing for extending
functionality.

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

<A NAME="cat-facade"></A>
<DT><B><A HREF="pat4efs.htm" TARGET="_mainDisplayFrame">Facade&nbsp;(<As+HREF="#Facade">185</A>)</B>
<DD>Provide a unified interface to a set of interfaces in a subsystem.
Facade defines a higher-level interface that makes the subsystem