chap1-1.htm

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

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

<TR VALIGN=TOP>
<TH BGCOLOR=#336699 ROWSPAN=2><FONT COLOR=#FFFFFF>Scope</FONT></TH>
<TH BGCOLOR=#6699CC>Class</TH>
<TD><A HREF="pat3cfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3cfs.htm" TARGET="_mainDisplayFrame">Factory Method (107)</A></TD>
<TD><A HREF="pat4afs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4afs.htm" TARGET="_mainDisplayFrame">Adapter (139)</A></TD>
<TD><A HREF="pat5cfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5cfs.htm" TARGET="_mainDisplayFrame">Interpreter (243)</A><BR>
<A HREF="pat5jfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5jfs.htm" TARGET="_mainDisplayFrame">Template Method (325)</A></TD>
</TR>

<TR VALIGN=TOP>
<TH BGCOLOR=#6699CC>Object</TH>
<TD><A HREF="pat3afs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3afs.htm" TARGET="_mainDisplayFrame">Abstract Factory (87)</A><BR>
<A HREF="pat3bfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3bfs.htm" TARGET="_mainDisplayFrame">Builder (97)</A><BR>
<A HREF="pat3dfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3dfs.htm" TARGET="_mainDisplayFrame">Prototype (117)</A><BR>
<A HREF="pat3efs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3efs.htm" TARGET="_mainDisplayFrame">Singleton (127)</A><BR>
</TD>

<TD><A HREF="pat4afs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4afs.htm" TARGET="_mainDisplayFrame">Adapter (139)</A><BR>
<A HREF="pat4bfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4bfs.htm" TARGET="_mainDisplayFrame">Bridge (151)</A><BR>
<A HREF="pat4cfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4cfs.htm" TARGET="_mainDisplayFrame">Composite (163)</A><BR>
<A HREF="pat4dfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4dfs.htm" TARGET="_mainDisplayFrame">Decorator (175)</A><BR>
<A HREF="pat4efs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4efs.htm" TARGET="_mainDisplayFrame">Facade (185</A>)<BR>
<A HREF="pat4gfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4gfs.htm" TARGET="_mainDisplayFrame">Proxy (207)</A><BR>
</TD>

<TD><A HREF="pat5afs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5afs.htm" TARGET="_mainDisplayFrame">Chain of Responsibility (223)</A><BR>
<A HREF="pat5bfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5bfs.htm" TARGET="_mainDisplayFrame">Command (233)</A><BR>
<A HREF="pat5dfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5dfs.htm" TARGET="_mainDisplayFrame">Iterator (257)</A><BR>
<A HREF="pat5efs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5efs.htm" TARGET="_mainDisplayFrame">Mediator (273)</A><BR>
<A HREF="pat5ffs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5ffs.htm" TARGET="_mainDisplayFrame">Memento (283)</A><BR>
<A HREF="pat4ffs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4ffs.htm" TARGET="_mainDisplayFrame">Flyweight (195</A>)<BR>
<A HREF="pat5gfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5gfs.htm" TARGET="_mainDisplayFrame">Observer (293)</A><BR>
<A HREF="pat5hfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5hfs.htm" TARGET="_mainDisplayFrame">State (305)</A><BR>
<A HREF="pat5ifs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5ifs.htm" TARGET="_mainDisplayFrame">Strategy (315)</A><BR>
<A HREF="pat5kfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5kfs.htm" TARGET="_mainDisplayFrame">Visitor (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 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="patmap-3.gif" tppabs="http://ultra/development/DesignPatterns/lowres/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="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next: How to Select a Design Pattern"></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
<a href="chapAfs-1.htm#object" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#object" target="_mainDisplayFrame">object</A> packages both data and the procedures that operate
on that data. The procedures are typically called <STRONG>methods</STRONG>
or <a href="chapAfs-1.htm#operation" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#operation" target="_mainDisplayFrame">operations</a>. An object performs an operation when it
receives a <a href="chapAfs-1.htm#request" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#request" target="_mainDisplayFrame">request</A> (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 <a href="chapAfs-1.htm#encapsulation" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#encapsulation" target="_mainDisplayFrame">encapsulated</a>; it cannot be accessed
directly, and its representation is invisible from outside the
object.</P>

<A NAME="auto1069"></A>
<P>The hard part about object-oriented design is decomposing a system
into objects.  The task is difficult because many factors come into
play: encapsulation, granularity, dependency, flexibility,
performance, evolution, reusability, and on and on.  They all
influence the decomposition, often in conflicting ways.</P>

<A NAME="auto1070"></A>
<P>Object-oriented design methodologies favor many different approaches.
You can write a problem statement, single out the nouns and verbs, and
create corresponding classes and operations. Or you can focus on the
collaborations and responsibilities in your system.  Or you can model
the real world and translate the objects found during analysis into
design.  There will always be disagreement on which approach is best.</P>

<A NAME="auto1071"></A>
<P>Many objects in a design come from the analysis model.  But
object-oriented designs often end up with classes that have no
counterparts in the real world.  Some of these are low-level
classes like arrays.  Others are much higher-level.  For example, the
<A HREF="pat4cfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4cfs.htm" TARGET="_mainDisplayFrame">Composite (163)</A> pattern introduces an abstraction for
treating objects uniformly that doesn't have a physical counterpart.
Strict modeling of the real world leads to a system that reflects
today's realities but not necessarily tomorrow's.  The abstractions
that emerge during design are key to making a design flexible.</P>

<A NAME="auto1072"></A>
<P>Design patterns help you identify less-obvious abstractions and the
objects that can capture them.  For example, objects that represent a
process or algorithm don't occur in nature, yet they are a crucial
part of flexible designs. The <A HREF="pat5ifs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5ifs.htm" TARGET="_mainDisplayFrame">Strategy (315)</A> pattern
describes how to implement interchangeable families of algorithms.
The <A HREF="pat5hfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5hfs.htm" TARGET="_mainDisplayFrame">State (305)</A> pattern represents each state of an entity
as an object.  These objects are seldom found during analysis or even
the early stages of design; they're discovered later in the course of
making a design more flexible and reusable.</P>

<H3>Determining Object Granularity</H3>

<A NAME="auto1073"></A>
<P>Objects can vary tremendously in size and number.  They can represent
everything down to the hardware or all the way up to entire
applications.  How do we decide what should be an object?</P>

<A NAME="auto1074"></A>
<P>Design patterns address this issue as well.  The
<A HREF="pat4efs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4efs.htm" TARGET="_mainDisplayFrame">Facade (185</A>) pattern describes how to represent complete
subsystems as objects, and the <A HREF="pat4ffs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4ffs.htm" TARGET="_mainDisplayFrame">Flyweight (195</A>) pattern
describes how to support huge numbers of objects at the finest
granularities.  Other design patterns describe specific ways of
decomposing an object into smaller objects.  <A HREF="pat3afs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3afs.htm" TARGET="_mainDisplayFrame">Abstract Factory (87)</A> and <A HREF="pat3bfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3bfs.htm" TARGET="_mainDisplayFrame">Builder (97)</A>
yield objects whose only responsibilities are creating other objects.
<A HREF="pat5kfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5kfs.htm" TARGET="_mainDisplayFrame">Visitor (331)</A> and <A HREF="pat5bfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5bfs.htm" TARGET="_mainDisplayFrame">Command (233)</A> yield
objects whose only responsibilities are to implement a request on
another object or group of objects.</P>

<A NAME="def-signature"></A>
<H3>Specifying Object Interfaces</H3>

<A NAME="auto1075"></A>
<P>Every operation declared by an object specifies the operation's name,
the objects it takes as parameters, and the operation's return value.
This is known as the operation's <a href="chapAfs-1.htm#signature" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#signature" target="_mainDisplayFrame">signature</A>.  The set of
all signatures defined by an object's operations is called the
<a href="chapAfs-1.htm#interface" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#interface" target="_mainDisplayFrame">interface</A> to the object. An object's interface
characterizes the complete set of requests that can be sent to the
object. Any request that matches a signature in the object's interface
may be sent to the object.</P>

<A NAME="def-type"></A>
<A NAME="def-subtype"></A>
<A NAME="def-supertype"></A>
<P>A <a href="chapAfs-1.htm#type" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#type" target="_mainDisplayFrame">type</A> is a name used to denote a particular interface. We
speak of an object as having the type "Window" if it accepts all
requests for the operations defined in the interface named "Window."
An object may have many types, and widely different objects can share
a type. Part of an object's interface may be characterized by one
type, and other parts by other types. Two objects of the same type
need only share parts of their interfaces.  Interfaces can contain
other interfaces as subsets. We say that a type is a <a href="chapAfs-1.htm#subtype" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#subtype" target="_mainDisplayFrame">subtype</A> of
another if its interface contains the interface of its
<a href="chapAfs-1.htm#supertype" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#supertype" target="_mainDisplayFrame">supertype</A>.  Often we speak of a subtype <EM>inheriting</EM> the
interface of its supertype.</P>

<A NAME="auto1076"></A>
<P>Interfaces are fundamental in object-oriented systems.  Objects are
known only through their interfaces. There is no way to know anything
about an object or to ask it to do anything without going through its
interface.  An object's interface says nothing about its
implementation&#151;different objects are free to implement requests
differently.  That means two objects having completely different
implementations can have identical interfaces.</P>

<A NAME="dynamicbinding"></A>
<P>When a request is sent to an object, the particular operation that's
performed depends on <EM>both</EM> the request <EM>and</EM> the receiving
object.  Different objects that support identical requests may have
different implementations of the operations that fulfill these
requests. The run-time association of a request to an object and one
of its operations is known as <a href="chapAfs-1.htm#dynamicbinding" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#dynamicbinding" target="_mainDisplayFrame">dynamic binding</A>.</P>

<A NAME="def-polymorphism"></A>
<P>Dynamic binding means that issuing a request doesn't commit you to a
particular implementation until run-time. Consequently, you can write
programs that expect an object with a particular interface, knowing
that any object that has the correct interface will accept the
request.  Moreover, dynamic binding lets you substitute objects that
have identical interfaces for each other at run-time.  This
substitutability is known as <a href="chapAfs-1.htm#polymorphism" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#polymorphism" target="_mainDisplayFrame">polymorphism</A>, and it's a key
concept in object-oriented systems. It lets a client object make few
assumptions about other objects beyond supporting a particular
interface. Polymorphism simplifies the definitions of clients,
decouples objects from each other, and lets them vary their
relationships to each other at run-time.</P>

<A NAME="auto1077"></A>
<P>Design patterns help you define interfaces by identifying their key
elements and the kinds of data that get sent across an interface.  A
design pattern might also tell you what <EM>not</EM> to put in the