chap1-1.htm

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

<A NAME="auto1041"></A>
<P>The catalog beginning on <A HREF="patcafs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3afs.htm" TARGET="_mainDisplayFrame">Abstract Factory (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4afs.htm" TARGET="_mainDisplayFrame">Adapter (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4bfs.htm" TARGET="_mainDisplayFrame">Bridge (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3bfs.htm" TARGET="_mainDisplayFrame">Builder (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5afs.htm" TARGET="_mainDisplayFrame">Chain of Responsibility (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5bfs.htm" TARGET="_mainDisplayFrame">Command (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4cfs.htm" TARGET="_mainDisplayFrame">Composite (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4dfs.htm" TARGET="_mainDisplayFrame">Decorator (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4efs.htm" TARGET="_mainDisplayFrame">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
easier to use.

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

<A NAME="cat-factory"></A>
<DT><B><A HREF="pat3cfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3cfs.htm" TARGET="_mainDisplayFrame">Factory Method (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4ffs.htm" TARGET="_mainDisplayFrame">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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5cfs.htm" TARGET="_mainDisplayFrame">Interpreter (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5dfs.htm" TARGET="_mainDisplayFrame">Iterator (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5efs.htm" TARGET="_mainDisplayFrame">Mediator (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="pat5ffs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5ffs.htm" TARGET="_mainDisplayFrame">Memento (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5gfs.htm" TARGET="_mainDisplayFrame">Observer (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3dfs.htm" TARGET="_mainDisplayFrame">Prototype (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4gfs.htm" TARGET="_mainDisplayFrame">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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3efs.htm" TARGET="_mainDisplayFrame">Singleton (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5hfs.htm" TARGET="_mainDisplayFrame">State (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5ifs.htm" TARGET="_mainDisplayFrame">Strategy (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="pat5jfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5jfs.htm" TARGET="_mainDisplayFrame">Template Method (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-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5kfs.htm" TARGET="_mainDisplayFrame">Visitor (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="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next: How Design Patterns Solve Design Problems"></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 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=#336699>&nbsp;</TD>
<TH COLSPAN=3 BGCOLOR=#336699><FONT COLOR=#FFFFFF>Purpose</FONT></TH>