chap6.htm

Design Pattern 设计模式

<P>In fact, noticing that something is a pattern is the easy part.
All four of us are actively working on building object-oriented
systems, and we've found that it's easy to spot patterns when you
look at enough systems.  But <EM>finding</EM> patterns is much
easier than <EM>describing</EM> them.</P>

<A NAME="auto1018"></A>
<P>If you build systems and then reflect on what you build, you will see
patterns in what you do.  But it's hard to describe patterns so that
people who don't know them will understand them and realize why they
are important.  Experts immediately recognized the value of the
catalog in its early stages.  But the only ones who could understand
the patterns were those who had already used them.</P>

<A NAME="auto1019"></A>
<P>Since one of the main purposes of the book was to teach
object-oriented design to new designers, we knew we had to improve the
catalog.  We expanded the average size of a pattern from less than 2
to more than 10 pages by including a detailed motivating example and sample
code.  We also started examining the trade-offs and the various ways
of implementing the pattern.  This made the patterns easier to learn.</P>

<A NAME="auto1020"></A>
<P>Another important change over the past year has been a greater emphasis on
the problem that a pattern solves.  It's easiest to see a pattern as a
solution, as a technique that can be adapted and reused.  It's harder
to see when it is <EM>appropriate</EM>&#151;to characterize the problems it
solves and the context in which it's the best solution.  In general,
it's easier to see <EM>what</EM> someone is doing than to know <EM>why</EM>,
and the "why" for a pattern is the problem it solves.  Knowing
the purpose of a pattern is important too, because it helps us choose
patterns to apply.  It also helps us understand the design of existing
systems.  A pattern author must determine and characterize the problem
that the pattern solves, even if you have to do it after you've
discovered its solution.</P>

<A NAME="sec6-3"></A>
<H2><A HREF="#sec6-4"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: An Invitation"></A>
The Pattern Community</H2>

<A NAME="auto1021"></A>
<P>We aren't the only ones interested in writing books that catalog the
patterns experts use.  We are a part of a larger community interested
in patterns in general and software-related patterns in particular.
Christopher Alexander is the architect who first studied patterns in
buildings and communities and developed a "pattern language" for
generating them.  His work has inspired us time and again.  So it's
fitting and worthwhile to compare our work to his.  Then we'll look at
others' work in software-related patterns.</P>

<A NAME="alexander"></A>

<H3>Alexander's Pattern Languages</H3>

<A NAME="auto1022"></A>
<P>There are many ways in which our work is like Alexander's.  Both are
based on observing existing systems and looking for patterns in them.
Both have templates for describing patterns (although our templates are
quite different).  Both rely on natural language and lots of examples
to describe patterns rather than formal languages, and both give
rationales for each pattern.</P>

<A NAME="auto1023"></A>
<P>But there are just as many ways in which our works are different:</P>

<OL>

<A NAME="auto1024"></A>
<LI>People have been making buildings for thousands of years, and there
are many classic examples to draw upon.  We have been making software
systems for a relatively short time, and few are considered classics.</LI>

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

<A NAME="auto1026"></A>
<LI>Alexander gives an order in which his patterns should be used; we have
not.</LI>

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

<A NAME="auto1028"></A>
<LI>Alexander's patterns emphasize the problems they address, whereas
design patterns describe the solutions in more detail.</LI>

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

<A NAME="auto1030"></A>
<LI>Alexander claims his patterns will generate complete buildings.  We do
not claim that our patterns will generate complete programs.</LI>

</OL>

<A NAME="design-poetry"></A>
<P>When Alexander claims you can design a house simply by applying his
patterns one after another, he has goals similar to those of
object-oriented design methodologists who give step-by-step rules for
design.  Alexander doesn't deny the need for creativity; some of his
patterns require understanding the living habits of the people who
will use the building, and his belief in the "poetry" of design
implies a level of expertise beyond the pattern language
itself.<A NAME="fn1"></A><A HREF="#footnote1"><SUP>1</SUP></A>
But his description of how patterns
generate designs implies that a pattern language can make the design
process deterministic and repeatable.</P>

<A NAME="auto1031"></A>
<P>The Alexandrian point of view has helped us focus on design
trade-offs&#151;the different "forces" that help shape a design.  His
influence made us work harder to understand the applicability and
consequences of our patterns.  It also kept us from worrying about
defining a formal representation of patterns.  Although such a
representation might make automating patterns possible, at this stage
it's more important to explore the space of design patterns than to
formalize it.</P>

<A NAME="auto1032"></A>
<P>From Alexander's point of view, the patterns in this book do not form
a pattern language.  Given the variety of software systems that people
build, it's hard to see how we could provide a "complete" set of
patterns, one that offers step-by-step instructions for designing an
application.  We can do that for certain classes of applications, such
as report-writing or making a forms-entry system.  But our catalog is
just a collection of related patterns; we can't pretend it's a pattern
language.</P>

<A NAME="auto1033"></A>
<P>In fact, we think it's unlikely that there will <EM>ever</EM> be a
complete pattern language for software.  But it's certainly possible
to make one that is <EM>more</EM> complete.  Additions would have to
include frameworks and how to use them [<A HREF="bibfs.htm#hotdraw" TARGET="_mainDisplayFrame">Joh92</A>], patterns for
user interface design [<A HREF="bibfs.htm#beck-johnson_ecoop94" TARGET="_mainDisplayFrame">BJ94</A>], analysis
patterns [<A HREF="bibfs.htm#coad_patterns" TARGET="_mainDisplayFrame">Coa92</A>], and all the other aspects of developing
software.  Design patterns are just a part of a larger pattern
language for software.</P>

<A NAME="patt-lang-of-prog"></A>
<H3>Patterns in Software</H3>

<A NAME="anderson"></A>
<P>Our first collective experience in the study of software architecture
was at an OOPSLA '91 workshop led by Bruce Anderson.  The
workshop was dedicated to developing a handbook for software
architects.  (Judging from this book, we suspect "architecture
encyclopedia" will be a more appropriate name than "architecture
handbook.")  That first workshop has led to a series of meetings, the
most recent of which being the first conference on Pattern Languages
of Programs held in August 1994.  This has created a community of
people interested in documenting software expertise.</P>

<A NAME="knuth"></A>
<P>Of course, others have had this goal as well.  Donald Knuth's <EM>The
Art of Computer Programming</EM> [<A HREF="bibfs.htm#knuth_art" TARGET="_mainDisplayFrame">Knu73</A>] was one of the first
attempts to catalog software knowledge, though he focused on
describing algorithms.  Even so, the task proved too great to
finish.  The <EM>Graphics Gems</EM>
series [<A HREF="bibfs.htm#graphicsGems1" TARGET="_mainDisplayFrame">Gla90</A>, <A HREF="bibfs.htm#graphicsGems2" TARGET="_mainDisplay
Frame">Arv91</A>, <A HREF="bibfs.htm#graphicsGems3" TARGET="_mainDisplayFrame">Kir92</A>] is another
catalog of design knowledge, though it too tends to focus on
algorithms.  The Domain Specific Software Architecture program
sponsored by the U.S. Department of Defense [<A HREF="bibfs.htm#dod_dssap" TARGET="_mainDisplayFrame">GM92</A>]
concentrates on gathering architectural information.  The
knowledge-based software engineering community tries to represent
software-related knowledge in general.  There are many other groups
with goals at least a little like ours.</P>

<A NAME="auto1034"></A>
<P>James Coplien's <EM>Advanced C++: Programming Styles and
Idioms</EM> [<A HREF="bibfs.htm#coplien_idioms" TARGET="_mainDisplayFrame">Cop92</A>] has influenced us, too.  The patterns in
his book tend to be more C++-specific than our design patterns, and
his book contains lots of lower-level patterns as well.  But there is
some overlap, as we point out in our patterns.  Jim has been active in
the pattern community.  He's currently working on patterns that
describe people's roles in software development organizations.</P>

<A NAME="kentbeck"></A>
<P>There are a lot of other places in which to find descriptions
of patterns.  Kent Beck was one of the first people in the software
community to advocate Christopher Alexander's work.  In 1993 he
started writing a column in <EM>The Smalltalk Report</EM> on
Smalltalk patterns.  Peter Coad has also been collecting patterns
for some time.  His paper on patterns seems to us to contain mostly
analysis patterns [<A HREF="bibfs.htm#coad_patterns" TARGET="_mainDisplayFrame">Coa92</A>];
we haven't seen his latest patterns, though we know he is still
working on them.  We've heard of several books on patterns that
are in the works, but we haven't seen any of them, either.  All we
can do is let you know they're coming.  One of these books will be
from the Pattern Languages of Programs conference.</P>

<A NAME="sec6-4"></A>
<H2><A HREF="#sec6-5"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: A Parting Thought"></A>
An Invitation</H2>

<A NAME="auto1035"></A>
<P>What can you do if you are interested in patterns?  First, use them
and look for other patterns that fit the way you design.  
A lot of books and articles about patterns will be coming out
in the next few years,
so there will be plenty of sources for new patterns.  Develop your
vocabulary of patterns, and use it.  Use it when you talk with other
people about your designs.  Use it when you think and write about them.</P>

<A NAME="auto1036"></A>
<P>Second, be a critical consumer.  The design pattern catalog is the
result of hard work, not just ours but that of dozens of reviewers who
gave us feedback.  If you spot a problem or believe more
explanation is needed, contact us.  The same goes for any other catalog of
patterns:  Give the authors feedback!  One of the great things about
patterns is that they move design decisions out of the realm of vague
intuition.  They let authors be explicit about the trade-offs they
make.  This makes it easier to see what is wrong with their patterns
and to argue with them.  Take advantage of that.</P>

<A NAME="auto1037"></A>
<P>Third, look for patterns you use, and write them down.  Make them a
part of your documentation.  Show them to other people.  You don't
have to be in a research lab to find patterns.  In fact, finding
relevant patterns is nearly impossible if you don't have practical
experience.  Feel free to write your own catalog of patterns...but
make sure someone else helps you beat them into shape!</P>


<A NAME="design-density"></A>
<A NAME="sec6-5"></A>
<H2><A HREF="#last"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: navigation"></A>
A Parting Thought</H2>

<A NAME="auto1038"></A>
<P>The best designs will use many design patterns that dovetail and
intertwine to produce a greater whole. As Christopher Alexander says:</P>

<BLOCKQUOTE>

It is possible to make buildings by stringing together patterns, in a
rather loose way. A building made like this, is an assembly of
patterns. It is not dense. It is not profound. But it is also possible
to put patterns together in such a way that many patterns overlap in
the same physical space: the building is very dense; it has many
meanings captured in a small space; and through this density, it
becomes profound.

</BLOCKQUOTE>

<P ALIGN=RIGHT><CITE>A Pattern Language</CITE> [<A HREF="bibfs.htm#Alexander_pl" TARGET="_mainDisplayFrame">AIX+77</A>, page <EM>xli</EM>]</P>

<A NAME="last"></A>
<P><A HREF="#top"><IMG SRC="gifsb/up3.gif" BORDER=0></A><BR>
<A HREF="chapAfs.htm" TARGET="_mainDisplayFrame"><IMG SRC="gifsb/rightar3.gif"
	ALIGN=TOP BORDER=0></A> <A HREF="chapAfs.htm"
	TARGET="_mainDisplayFrame">Glossary</A><BR>
<A HREF="disc5fs.htm" TARGET="_mainDisplayFrame"><IMG SRC="gifsb/leftarr3.gif"
	ALIGN=TOP BORDER=0></A> <A HREF="disc5fs.htm"
	TARGET="_mainDisplayFrame">Discussion of Behavioral Patterns</A>
</P>

<HR>

<A NAME="footnote1"></A>
<P><SUP>1</SUP>See "The poetry of the
language" [<A HREF="bibfs.htm#Alexander_pl" TARGET="_mainDisplayFrame">AIS+77</A>].</P>

</BODY>

</HTML>