📄 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. Afterall, it doesn't present any algorithms or programming techniques thathaven't been used before. It doesn't give a rigorous method fordesigning systems, nor does it develop a new theory of design—itjust documents existing designs. You could conclude that itmakes a reasonable tutorial, perhaps, but it certainly can't offermuch to an experienced object-oriented designer.</P><A NAME="benefits"></A><P>We hope you think differently. Cataloging design patterns isimportant. It gives us standard names and definitions for thetechniques we use. If we don't study design patterns in software, wewon't be able to improve them, and it'll be harder to come up with newones.</P><A NAME="auto1000"></A><P>This book is only a start. It contains some of the most common designpatterns that expert object-oriented designers use, and yet peoplehear and learn about them solely by word of mouth or by studyingexisting systems. Early drafts of the book prompted other people towrite down the design patterns they use, and it should prompt evenmore in its current form. We hope this will mark the start of amovement to document the expertise of software practitioners.</P><A NAME="auto1001"></A><P>This chapter discusses the impact we think design patterns willhave, how they are related to other work in design, and how you canget 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 canaffect the way you design object-oriented software, based on ourday-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 haveshown that knowledge and experience isn't organized simply aroundsyntax but in larger conceptual structures such as algorithms, datastructures 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 particulargoal [<A HREF="bibfs.htm#soloway-erlich_empirical" TARGET="_mainDisplayFrame">SE84</A>].Designers probably don't think about the notation they're usingfor recording the design as much as they try to match the currentdesign situation against plans, algorithms, data structures, andidioms 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 patternsprovide a common vocabulary for designers to use to communicate, document,and explore design alternatives. Design patterns make a system seemless complex by letting you talk about it at a higher level ofabstraction than that of a design notation or programming language.Design patterns raise the level at which you design and discuss designwith your colleagues.</P><A NAME="auto1004"></A><P>Once you've absorbed the design patterns in this book, your designvocabulary will almost certainly change. You will speak directly interms of the names of the design patterns. You'll find yourselfsaying things like, "Let's use an Observer here," or, "Let's make aStrategy 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 understandexisting systems. Most large object-oriented systems use these designpatterns. People learning object-oriented programming often complainthat the systems they're working with use inheritance in convolutedways and that it's difficult to follow the flow of control. In largepart this is because they do not understand the design patterns in thesystem. Learning these design patterns will help you understandexisting object-oriented systems.</P><A NAME="auto1006"></A><P>These design patterns can also make you a better designer. Theyprovide solutions to common problems. If you work withobject-oriented systems long enough, you'll probably learn thesedesign patterns on your own. But reading the book will help you learnthem much faster. Learning these patterns will help a novice act morelike an expert.</P><A NAME="auto1007"></A><P>Moreover, describing a system in terms of the design patterns that ituses will make it a lot easier to understand. Otherwise, people willhave to reverse-engineer the design to unearth the patterns it uses.Having a common vocabulary means you don't have to describe the wholedesign pattern; you can just name it and expect your reader to knowit. A reader who doesn't know the patterns will have to look them upat 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 theminvaluable. Yet we use the patterns in arguably naive ways. We usethem to pick names for classes, to think about and teach good design,and to describe designs in terms of the sequence of design patterns weapplied [<A HREF="bibfs.htm#beck-johnson_ecoop94" TARGET="_mainDisplayFrame">BJ94</A>]. It's easy to imagine moresophisticated ways of using patterns, such as pattern-based CASE toolsor hypertext documents. But patterns are a big help even withoutsophisticated 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, toteach new designers how to design well, and to standardize the waydesigns are developed. A design method typically defines a set ofnotations (usually graphical) for modeling various aspects of a design,along with a set of rules that govern how and when to use eachnotation. Design methods usually describe problems that occur in adesign, how to resolve them, and how to evaluate design. But theyhaven'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 beenmissing from object-oriented design methods. The design patterns showhow to use primitive techniques such as objects, inheritance, andpolymorphism. They show how to parameterize a system with analgorithm, a behavior, a state, or the kind of objects it's supposedto 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 thedesign 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 modelinto an implementation model. Despite many claims that promise asmooth transition from object-oriented analysis to design, in practicethe transition is anything but smooth. A flexible and reusable designwill contain objects that aren't in the analysis model. Theprogramming language and class libraries you use affect the design.Analysis models often must be redesigned to make them reusable. Manyof the design patterns in the catalog address these issues, which iswhy we call them <EM>design</EM> patterns.</P><A NAME="auto1011"></A><P>A full-fledged design method requires more kinds of patterns than justdesign patterns. There can also be analysis patterns, user interfacedesign patterns, or performance-tuning patterns. But the designpatterns 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 itoften has to be reorganized or <STRONG>refactored</STRONG> [<A HREF="bibfs.htm#opdyke-johnson_refactoring" TARGET="_mainDisplayFrame">OJ90</A>]. Designpatterns help you determine how to reorganize a design, and theycan 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 isbrought 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 thatclosely reflect entities in the initial problem domain. The main kindof 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, itsevolution is governed by two conflicting needs: (1) the software mustsatisfy more requirements, and (2) the software must be more reusable.New requirements usually add new classes and operations and perhapswhole class hierarchies. The software goes through an expansionaryphase to meet new requirements. This can't continue for long,however. Eventually the software will become too inflexible andarthritic for further change. The class hierarchies will no longermatch any problem domain. Instead they'll reflect many problemdomains, and classes will define many unrelated operations andinstance variables.</P><A NAME="blackbox-reuse"></A><A NAME="whitebox-reuse"></A><P>To continue to evolve, the software must be reorganized in a processknown as <EM>refactoring</EM>. This is the phase in which frameworksoften emerge. Refactoring involves tearing apart classes into special-and general-purpose components, moving operations up or down the classhierarchy, and rationalizing the interfaces of classes. Thisconsolidation phase produces many new kinds of objects, often bydecomposing existing objects and using object composition instead ofinheritance. Hence black-box reuse replaces white-box reuse. Thecontinual need to satisfy more requirements along with the need formore reuse propels object-oriented software through repeated phases ofexpansion and consolidation—expansion as new requirements aresatisfied, 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 thechanges that can prompt refactorings. Good designers also know classand object structures that can help avoid refactorings—their designsare robust in the face of requirement changes. A thoroughrequirements analysis will highlight those requirements that arelikely to change during the life of the software, and a good designwill be robust to them.</P><A NAME="auto1015"></A><P>Our design patterns capture many of the structures that result fromrefactoring. Using these patterns early in the life of a designprevents later refactorings. But even if you don't see how to apply apattern until after you've built your system, the pattern canstill show you how to change it. Design patterns thus provide targetsfor 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="_mainDisplayFrame">Gam92</A>]. Roughly half of thecurrent patterns were in his thesis. By OOPSLA '91 it was officiallyan independent catalog, and Richard had joined Erich to work on it.John started working on it soon thereafter. By OOPSLA '92, Ralph hadjoined the group. We worked hard to make the catalog fit forpublication at ECOOP '93, but soon we realized that a 90-page paperwas not going to be accepted. So we summarized the catalog andsubmitted the summary, which was accepted. We decided to turn thecatalog 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 importantenough. But otherwise the set of patterns in the catalog has changedlittle since the end of 1992. The patterns themselves, however, haveevolved tremendously.</P><A NAME="despatt-finding"></A>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -