📄 chap6.htm
字号:
<HTML><HEAD> <TITLE>Conclusion</TITLE>
<SCRIPT>
function setFocus() {
if ((navigator.appName != "Netscape") && (parseFloat(navigator.appVersion) == 2)) {
return;
} else {
self.focus();
}
}
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" onLoad="setFocus();">
<A NAME="top"></A>
<P>It's possible to argue that this book hasn't accomplished much. After
all, it doesn't present any algorithms or programming techniques that
haven't been used before. It doesn't give a rigorous method for
designing systems, nor does it develop a new theory of design—it
just documents existing designs. You could conclude that it
makes a reasonable tutorial, perhaps, but it certainly can't offer
much to an experienced object-oriented designer.</P>
<A NAME="benefits"></A>
<P>We hope you think differently. Cataloging design patterns is
important. It gives us standard names and definitions for the
techniques we use. If we don't study design patterns in software, we
won't be able to improve them, and it'll be harder to come up with new
ones.</P>
<A NAME="auto1000"></A>
<P>This book is only a start. It contains some of the most common design
patterns that expert object-oriented designers use, and yet people
hear and learn about them solely by word of mouth or by studying
existing systems. Early drafts of the book prompted other people to
write down the design patterns they use, and it should prompt even
more in its current form. We hope this will mark the start of a
movement to document the expertise of software practitioners.</P>
<A NAME="auto1001"></A>
<P>This chapter discusses the impact we think design patterns will
have, how they are related to other work in design, and how you can
get involved in finding and cataloging patterns.</P>
<A NAME="sec6-1"></A>
<H2><A HREF="#sec6-2"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: A Brief History"></A>
What to Expect from Design Patterns</H2>
<A NAME="auto1002"></A>
<P>Here are several ways in which the design patterns in this book can
affect the way you design object-oriented software, based on our
day-to-day experience with them.</P>
<A NAME="common-vocab"></A>
<H3>A Common Design Vocabulary</H3>
<A NAME="auto1003"></A>
<P>Studies of expert programmers for conventional languages have
shown that knowledge and experience isn't organized simply around
syntax but in larger conceptual structures such as algorithms, data
structures and idioms [<A HREF="bibfs.htm#adelson-soloway_domain" TARGET="_mainDisplayFrame">AS85</A>, <A HREF="bibfs.htm#coplien_idioms" TARGET="_mainDisplayFrame">Cop92</A>, <A HREF="bibfs.htm#curtis_cognitive" TARGET="_mainDisplayFrame">Cur89</A>, <A HREF="bibfs.htm#spopher-soloway_mistakes" TARGET="_mainDisplayFrame">SS86</A>], and plans for fulfilling a particular
goal [<A HREF="bibfs.htm#soloway-erlich_empirical" TARGET="_mainDisplayFrame">SE84</A>].
Designers probably don't think about the notation they're using
for recording the design as much as they try to match the current
design situation against plans, algorithms, data structures, and
idioms they have learned in the past.</P>
<A NAME="despatt-doc"></A>
<P>Computer scientists name and catalog algorithms and data structures,
but we don't often name other kinds of patterns. Design patterns
provide a common vocabulary for designers to use to communicate, document,
and explore design alternatives. Design patterns make a system seem
less complex by letting you talk about it at a higher level of
abstraction than that of a design notation or programming language.
Design patterns raise the level at which you design and discuss design
with your colleagues.</P>
<A NAME="auto1004"></A>
<P>Once you've absorbed the design patterns in this book, your design
vocabulary will almost certainly change. You will speak directly in
terms of the names of the design patterns. You'll find yourself
saying things like, "Let's use an Observer here," or, "Let's make a
Strategy out of these classes."</P>
<A NAME="design-docpatt"></A>
<H3>A Documentation and Learning Aid</H3>
<A NAME="auto1005"></A>
<P>Knowing the design patterns in this book makes it easier to understand
existing systems. Most large object-oriented systems use these design
patterns. People learning object-oriented programming often complain
that the systems they're working with use inheritance in convoluted
ways and that it's difficult to follow the flow of control. In large
part this is because they do not understand the design patterns in the
system. Learning these design patterns will help you understand
existing object-oriented systems.</P>
<A NAME="auto1006"></A>
<P>These design patterns can also make you a better designer. They
provide solutions to common problems. If you work with
object-oriented systems long enough, you'll probably learn these
design patterns on your own. But reading the book will help you learn
them much faster. Learning these patterns will help a novice act more
like an expert.</P>
<A NAME="auto1007"></A>
<P>Moreover, describing a system in terms of the design patterns that it
uses will make it a lot easier to understand. Otherwise, people will
have to reverse-engineer the design to unearth the patterns it uses.
Having a common vocabulary means you don't have to describe the whole
design pattern; you can just name it and expect your reader to know
it. A reader who doesn't know the patterns will have to look them up
at first, but that's still easier than reverse-engineering.</P>
<A NAME="auto1008"></A>
<P>We use these patterns in our own designs, and we've found them
invaluable. Yet we use the patterns in arguably naive ways. We use
them to pick names for classes, to think about and teach good design,
and to describe designs in terms of the sequence of design patterns we
applied [<A HREF="bibfs.htm#beck-johnson_ecoop94" TARGET="_mainDisplayFrame">BJ94</A>]. It's easy to imagine more
sophisticated ways of using patterns, such as pattern-based CASE tools
or hypertext documents. But patterns are a big help even without
sophisticated tools.</P>
<A NAME="design-obj-mod"></A>
<A NAME="design-adjunct"></A>
<H3>An Adjunct to Existing Methods</H3>
<A NAME="auto1009"></A>
<P>Object-oriented design methods are supposed to promote good design, to
teach new designers how to design well, and to standardize the way
designs are developed. A design method typically defines a set of
notations (usually graphical) for modeling various aspects of a design,
along with a set of rules that govern how and when to use each
notation. Design methods usually describe problems that occur in a
design, how to resolve them, and how to evaluate design. But they
haven't been able to capture the experience of expert designers.</P>
<A NAME="auto1010"></A>
<P>We believe our design patterns are an important piece that's been
missing from object-oriented design methods. The design patterns show
how to use primitive techniques such as objects, inheritance, and
polymorphism. They show how to parameterize a system with an
algorithm, a behavior, a state, or the kind of objects it's supposed
to create. Design patterns provide a way to describe more of the
"why" of a design and not just record the results of your decisions.
The Applicability, Consequences, and Implementation sections of the
design patterns help guide you in the decisions you have to make.</P>
<A NAME="objectmodel"></A>
<P>Design patterns are especially useful in turning an analysis model
into an implementation model. Despite many claims that promise a
smooth transition from object-oriented analysis to design, in practice
the transition is anything but smooth. A flexible and reusable design
will contain objects that aren't in the analysis model. The
programming language and class libraries you use affect the design.
Analysis models often must be redesigned to make them reusable. Many
of the design patterns in the catalog address these issues, which is
why we call them <EM>design</EM> patterns.</P>
<A NAME="auto1011"></A>
<P>A full-fledged design method requires more kinds of patterns than just
design patterns. There can also be analysis patterns, user interface
design patterns, or performance-tuning patterns. But the design
patterns are an essential part, one that's been missing until now.</P>
<A NAME="despatt-refactor"></A>
<A NAME="refactor"></A>
<H3>A Target for Refactoring</H3>
<A NAME="auto1012"></A>
<P>One of the problems in developing reusable software is that it
often has to be reorganized or <STRONG>refactored</STRONG> [<A HREF="bibfs.htm#opdyke-johnson_refactoring" TARGET="_mainDisplayFrame">OJ90</A>]. Design
patterns help you determine how to reorganize a design, and they
can reduce the amount of refactoring you need to do later.</P>
<A NAME="exp-phase1"></A>
<A NAME="foote"></A>
<A NAME="proto-phase"></A>
<P>The lifecycle of object-oriented software has several phases.
Brian Foote identifies these phases as the <STRONG>prototyping</STRONG>,
<STRONG>expansionary</STRONG>, and <STRONG>consolidating</STRONG>
phases [<A HREF="bibfs.htm#Foote-Fractal" TARGET="_mainDisplayFrame">Foo92</A>].</P>
<A NAME="auto1013"></A>
<P>The prototyping phase is a flurry of activity as the software is
brought to life through rapid prototyping and incremental changes,
until it meets an initial set of requirements and reaches adolescence.
At this point, the software usually consists of class hierarchies that
closely reflect entities in the initial problem domain. The main kind
of reuse is white-box reuse by inheritance.</P>
<A NAME="exp-phase2"></A>
<P>Once the software has reached adolescence and is put into service, its
evolution is governed by two conflicting needs: (1) the software must
satisfy more requirements, and (2) the software must be more reusable.
New requirements usually add new classes and operations and perhaps
whole class hierarchies. The software goes through an expansionary
phase to meet new requirements. This can't continue for long,
however. Eventually the software will become too inflexible and
arthritic for further change. The class hierarchies will no longer
match any problem domain. Instead they'll reflect many problem
domains, and classes will define many unrelated operations and
instance variables.</P>
<A NAME="blackbox-reuse"></A>
<A NAME="whitebox-reuse"></A>
<P>To continue to evolve, the software must be reorganized in a process
known as <EM>refactoring</EM>. This is the phase in which frameworks
often emerge. Refactoring involves tearing apart classes into special-
and general-purpose components, moving operations up or down the class
hierarchy, and rationalizing the interfaces of classes. This
consolidation phase produces many new kinds of objects, often by
decomposing existing objects and using object composition instead of
inheritance. Hence black-box reuse replaces white-box reuse. The
continual need to satisfy more requirements along with the need for
more reuse propels object-oriented software through repeated phases of
expansion and consolidation—expansion as new requirements are
satisfied, and consolidation as the software becomes more general.</P>
<A NAME="lifecycle-gif"></A>
<P ALIGN=CENTER><IMG SRC="Pictures/lifec036.gif"></P>
<A NAME="auto1014"></A>
<P>This cycle is unavoidable. But good designers are aware of the
changes that can prompt refactorings. Good designers also know class
and object structures that can help avoid refactorings—their designs
are robust in the face of requirement changes. A thorough
requirements analysis will highlight those requirements that are
likely to change during the life of the software, and a good design
will be robust to them.</P>
<A NAME="auto1015"></A>
<P>Our design patterns capture many of the structures that result from
refactoring. Using these patterns early in the life of a design
prevents later refactorings. But even if you don't see how to apply a
pattern until after you've built your system, the pattern can
still show you how to change it. Design patterns thus provide targets
for your refactorings.</P>
<A NAME="sec6-2"></A>
<H2><A HREF="#sec6-3"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: The Pattern
Community"></A> A Brief History</H2>
<A NAME="auto1016"></A>
<P>The catalog began as a part of Erich's Ph.D.
thesis [<A HREF="bibfs.htm#gamma_thesis" TARGET="_mainDisplayFrame">Gam91</A>, <A HREF="bibfs.htm#gamma_thesis-book" TARGET="_mainDisp
layFrame">Gam92</A>]. Roughly half of the
current patterns were in his thesis. By OOPSLA '91 it was officially
an independent catalog, and Richard had joined Erich to work on it.
John started working on it soon thereafter. By OOPSLA '92, Ralph had
joined the group. We worked hard to make the catalog fit for
publication at ECOOP '93, but soon we realized that a 90-page paper
was not going to be accepted. So we summarized the catalog and
submitted the summary, which was accepted. We decided to turn the
catalog into a book shortly thereafter.</P>
<A NAME="auto1017"></A>
<P>Our names for the patterns have changed a little along the way.
"Wrapper" became "Decorator," "Glue" became "Facade,"
"Solitaire" became "Singleton," and "Walker" became "Visitor."
A couple of patterns got dropped because they didn't seem important
enough. But otherwise the set of patterns in the catalog has changed
little since the end of 1992. The patterns themselves, however, have
evolved tremendously.</P>
<A NAME="despatt-finding"></A>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -