chap1.htm

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

easier to use.

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

<A NAME="cat-factory"></A>
<DT><B><A HREF="pat3cfs.htm" TARGET="_mainDisplayFrame">Factory Method&nbsp;(107)</A></B>
<DD>Define an interface for creating an object, but let subclasses decide
which class to instantiate. Factory Method lets a class defer
instantiation to subclasses.

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

<A NAME="cat-flywt"></A>
<DT><B><A HREF="pat4ffs.htm" TARGET="_mainDisplayFrame">Flyweight&nbsp;(<As+HREF="#Flyweight">195</A>)</B>
<DD>Use sharing to support large numbers of fine-grained objects efficiently.

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

<DT><B><A HREF="pat5cfs.htm" TARGET="_mainDisplayFrame">Interpreter&nbsp;(243)</A></B>
<DD>Given a language, define a represention for its grammar along with an
interpreter that uses the representation to interpret sentences in the
language.

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

<DT><B><A HREF="pat5dfs.htm" TARGET="_mainDisplayFrame">Iterator&nbsp;(257)</A></B>
<DD>Provide a way to access the elements of an aggregate object
sequentially without exposing its underlying representation.

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

<A NAME="cat-media"></A>
<DT><B><A HREF="pat5efs.htm" TARGET="_mainDisplayFrame">Mediator&nbsp;(273)</A></B>
<DD>Define an object that encapsulates how a set of objects interact.
Mediator promotes loose coupling by keeping objects from referring to
each other explicitly, and it lets you vary their interaction
independently.

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

<A NAME="cat-memen"></A>
<DT><B><A HREF="pat5efs.htm" TARGET="_mainDisplayFrame">Memento&nbsp;(283)</A></B>
<DD>Without violating encapsulation, capture and externalize an object's
internal state so that the object can be restored to this state later.

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

<DT><B><A HREF="pat5gfs.htm" TARGET="_mainDisplayFrame">Observer&nbsp;(293)</A></B>
<DD>Define a one-to-many dependency between objects so that when one
object changes state, all its dependents are notified and updated
automatically.

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

<A NAME="cat-proto"></A>
<DT><B><A HREF="pat3dfs.htm" TARGET="_mainDisplayFrame">Prototype&nbsp;(117)</A></B>
<DD>Specify the kinds of objects to create using a prototypical
instance, and create new objects by copying this prototype.

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

<A NAME="cat-proxy"></A>
<DT><B><A HREF="pat4gfs.htm" TARGET="_mainDisplayFrame">Proxy&nbsp;(<As+HREF="#Proxy">207</A>)</B>
<DD>Provide a surrogate or placeholder for another object to control
access to it.

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

<A NAME="cat-single"></A>
<DT><B><A HREF="pat3efs.htm" TARGET="_mainDisplayFrame">Singleton&nbsp;(127)</A></B>
<DD>Ensure a class only has one instance, and provide a global point
of access to it.

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

<A NAME="cat-state"></A>
<DT><B><A HREF="pat5hfs.htm" TARGET="_mainDisplayFrame">State&nbsp;(305)</A></B>
<DD>Allow an object to alter its behavior when its internal state changes.
The object will appear to change its class.

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

<A NAME="cat-strat"></A>
<DT><B><A HREF="pat5ifs.htm" TARGET="_mainDisplayFrame">Strategy&nbsp;(315)</A></B>
<DD>Define a family of algorithms, encapsulate each one, and make them
interchangeable.  Strategy lets the algorithm vary independently from
clients that use it.

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

<A NAME="cat-tempmeth"></A>
<DT><B><A HREF="pat5ifs.htm" TARGET="_mainDisplayFrame">Template Method&nbsp;(325)</A></B>
<DD>Define the skeleton of an algorithm in an operation, deferring some
steps to subclasses. Template Method lets subclasses redefine
certain steps of an algorithm without changing the algorithm's
structure.

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

<A NAME="cat-visit"></A>
<DT><B><A HREF="pat5kfs.htm" TARGET="_mainDisplayFrame">Visitor&nbsp;(331)</A></B>
<DD>Represent an operation to be performed on the elements of an object
structure.  Visitor lets you define a new operation without changing the
classes of the elements on which it operates.

</DL>

<A NAME="sec1-5"></A>
<H2><A HREF="#sec1-6"><IMG SRC="gifsb/down3.gif" BORDER=0></A>
Organizing the Catalog</H2>

<A NAME="sect_catalog_organization"></A>
<P>Design patterns vary in their granularity and level of abstraction.
Because there are many design patterns, we need a way to organize
them.  This section classifies design patterns so that we can refer to
families of related patterns.  The classification helps you learn the
patterns in the catalog faster, and it can direct efforts to find
new patterns as well.</P>

<A NAME="behpat"></A>
<A NAME="structural-pattern"></A>
<P>We classify design patterns by two criteria
(<A HREF="#space">Table&nbsp;1.1</A>). The first criterion, called
<STRONG>purpose</STRONG>, reflects what a pattern does.  Patterns can
have either <STRONG>creational</STRONG>, <STRONG>structural</STRONG>, or
<STRONG>behavioral</STRONG> purpose. Creational patterns concern the
process of object creation.  Structural patterns deal with the
composition of classes or objects.  Behavioral patterns characterize
the ways in which classes or objects interact and distribute
responsibility.</P>

<A NAME="space"></A>

<CENTER>
<TABLE	
	BORDER		= 1
	CELLPADDING	= 4
	CELLSPACING	= 0
	BGCOLOR		= #99CCFF
>

<TR VALIGN=TOP>
<TD COLSPAN=2 ROWSPAN=2 BGCOLOR=#6699CC>&nbsp;</TD>
<TH COLSPAN=3 BGCOLOR=#336699><FONT COLOR=#FFFFFF>Purpose</FONT></TH>

<TR VALIGN=TOP>
<TH BGCOLOR=#6699CC>Creational</TH>
<TH BGCOLOR=#6699CC>Structural</TH>
<TH BGCOLOR=#6699CC>Behavioral</TH>
</TR>

<TR VALIGN=TOP>
<TH ROWSPAN=2>Scope</TH>
<TH>Class</TH>
<TD><A HREF="pat3cfs.htm" TARGET="_mainDisplayFrame">Factory Method&nbsp;(107)</A></TD>
<TD><A HREF="pat4afs.htm" TARGET="_mainDisplayFrame">Adapter&nbsp;(139)</A></TD>
<TD><A HREF="pat5cfs.htm" TARGET="_mainDisplayFrame">Interpreter&nbsp;(243)</A><BR>
<A HREF="pat5jfs.htm" TARGET="_mainDisplayFrame">Template Method&nbsp;(325)</A></TD>
</TR>

<TR VALIGN=TOP>
<TH>Object</TH>
<TD><A HREF="pat3afs.htm" TARGET="_mainDisplayFrame">Abstract Factory&nbsp;(87)</A><BR>
<A HREF="pat3bfs.htm" TARGET="_mainDisplayFrame">Builder&nbsp;(97)</A><BR>
<A HREF="pat3dfs.htm" TARGET="_mainDisplayFrame">Prototype&nbsp;(117)</A><BR>
<A HREF="pat3efs.htm" TARGET="_mainDisplayFrame">Singleton&nbsp;(127)</A><BR>
</TD>

<TD><A HREF="pat4afs.htm" TARGET="_mainDisplayFrame">Adapter&nbsp;(139)</A><BR>
<A HREF="pat4bfs.htm" TARGET="_mainDisplayFrame">Bridge&nbsp;(151)</A><BR>
<A HREF="pat4cfs.htm" TARGET="_mainDisplayFrame">Composite&nbsp;(163)</A><BR>
<A HREF="pat4dfs.htm" TARGET="_mainDisplayFrame">Decorator&nbsp;(175)</A><BR>
<A HREF="pat4efs.htm" TARGET="_mainDisplayFrame">Facade&nbsp;(<As+HREF="#Facade">185</A>)<BR>
<A HREF="pat4gfs.htm" TARGET="_mainDisplayFrame">Proxy&nbsp;(<As+HREF="#Proxy">207</A>)<BR>
</TD>

<TD><A HREF="pat5afs.htm" TARGET="_mainDisplayFrame">Chain of Responsibility&nbsp;(223)</A><BR>
<A HREF="pat5bfs.htm" TARGET="_mainDisplayFrame">Command&nbsp;(233)</A><BR>
<A HREF="pat5dfs.htm" TARGET="_mainDisplayFrame">Iterator&nbsp;(257)</A><BR>
<A HREF="pat5efs.htm" TARGET="_mainDisplayFrame">Mediator&nbsp;(273)</A><BR>
<A HREF="pat5efs.htm" TARGET="_mainDisplayFrame">Memento&nbsp;(283)</A><BR>
<A HREF="pat4ffs.htm" TARGET="_mainDisplayFrame">Flyweight&nbsp;(<As+HREF="#Flyweight">195</A>)<BR>
<A HREF="pat5gfs.htm" TARGET="_mainDisplayFrame">Observer&nbsp;(293)</A><BR>
<A HREF="pat5hfs.htm" TARGET="_mainDisplayFrame">State&nbsp;(305)</A><BR>
<A HREF="pat5ifs.htm" TARGET="_mainDisplayFrame">Strategy&nbsp;(315)</A><BR>
<A HREF="pat5kfs.htm" TARGET="_mainDisplayFrame">Visitor&nbsp;(331)</A><BR>
</TD>

</TABLE></CENTER>

<P ALIGN=CENTER>Table 1.1:&nbsp;&nbsp;Design pattern space</P>

<A NAME="despatt-scope"></A>
<P>The second criterion, called <STRONG>scope</STRONG>, specifies whether the
pattern applies primarily to classes or to objects.  Class patterns
deal with relationships between classes and their subclasses.  These
relationships are established through inheritance, so they are
static&#151;fixed at compile-time.  Object patterns deal with object
relationships, which can be changed at run-time and are more dynamic.
Almost all patterns use inheritance to some extent.  So the only
patterns labeled "class patterns" are those that focus on class
relationships.  Note that most patterns are in the Object scope.</P>

<A NAME="auto1064"></A>
<P>Creational class patterns defer some part of object creation to
subclasses, while Creational object patterns defer it to another
object.  The Structural class patterns use inheritance to compose
classes, while the Structural object patterns describe ways to
assemble objects.  The Behavioral class patterns use inheritance to
describe algorithms and flow of control, whereas the Behavioral object
patterns describe how a group of objects cooperate to perform a task
that no single object can carry out alone.</P>

<A NAME="auto1065"></A>
<P>There are other ways to organize the patterns.  Some patterns are
often used together.  For example, Composite is often used with
Iterator or Visitor.  Some patterns are alternatives: Prototype is
often an alternative to Abstract Factory.  Some patterns result in
similar designs even though the patterns have different intents.  For
example, the structure diagrams of Composite and Decorator are
similar.</P>

<A NAME="auto1066"></A>
<P>Yet another way to organize design patterns is according to how they
reference each other in their "Related Patterns" sections.
<A HREF="#intro_overview">Figure&nbsp;1.1</A> depicts these relationships graphically.</P>

<A NAME="auto1067"></A>
<P>Clearly there are many ways to organize design patterns.  Having
multiple ways of thinking about patterns will deepen your insight into
what they do, how they compare, and when to apply them.</P>

<A NAME="intro_overview">
<P ALIGN=CENTER
><IMG SRC="Pictures/patmap.gif" ISMAP BORDER=0 USEMAP="#patmap"><BR><BR>
Figure 1.1:&nbsp;&nbsp;Design pattern relationships</P>

<A NAME="sec1-6"></A>
<H2><A HREF="#sec1-7"><IMG SRC="gifsb/down3.gif" BORDER=0></A>
How Design Patterns Solve Design Problems</H2>

<A NAME="sect_how_design_patterns_solve_design_problems"></A>
<P>Design patterns solve many of the day-to-day problems object-oriented
designers face, and in many different ways.  Here are several of these
problems and how design patterns solve them.</P>

<A NAME="findingappropriate"></A>
<H3>Finding Appropriate Objects</H3>

<A NAME="auto1068"></A>
<P>Object-oriented programs are made up of objects. An
<STRONG>object</STRONG> packages both data and the procedures that operate
on that data. The procedures are typically called <STRONG>methods</STRONG>
or <STRONG>operations</STRONG>. An object performs an operation when it
receives a <STRONG>request</STRONG> (or <STRONG>message</STRONG>) from a
<STRONG>client</STRONG>.</P>

<A NAME="encapsulation"></A>
<P>Requests are the <EM>only</EM> way to get an object to execute an
operation. Operations are the <EM>only</EM> way to change an object's
internal data. Because of these restrictions, the object's internal
state is said to be <STRONG>encapsulated</STRONG>; it cannot be accessed
directly, and its representation is invisible from outside the