📄 chap1-1.htm
字号:
<HTML>
<HEAD>
<TITLE>Introduction</TITLE>
<SCRIPT>
function setFocus() {
if ((navigator.appName != "Netscape") && (parseFloat(navigator.appVersion) == 2)) {
return;
} else {
self.focus();
}
}
</SCRIPT></HEAD>
<BODY BGCOLOR = #FFFFFF
TEXT = #000000
onLoad="setFocus()";
>
<A NAME="top"></A>
<P>Designing object-oriented software is hard, and designing
<EM>reusable</EM> object-oriented software is even harder. You
must find pertinent objects, factor them into classes at the right
granularity, define class interfaces and inheritance hierarchies,
and establish key relationships among them. Your design should be
specific to the problem at hand but also general enough to address
future problems and requirements. You also want to avoid redesign,
or at least minimize it. Experienced object-oriented designers
will tell you that a reusable and flexible design is difficult if
not impossible to get "right" the first time. Before a design is
finished, they usually try to reuse it several times, modifying it
each time.</P>
<A NAME="auto1000"></A>
<P>Yet experienced object-oriented designers do make good designs.
Meanwhile new designers are overwhelmed by the options available and
tend to fall back on non-object-oriented techniques they've used
before. It takes a long time for novices to learn what good
object-oriented design is all about. Experienced designers evidently
know something inexperienced ones don't. What is it?</P>
<A NAME="auto1001"></A>
<P>One thing expert designers know <EM>not</EM> to do is solve every problem
from first principles. Rather, they reuse solutions that have worked
for them in the past. When they find a good solution, they use it
again and again. Such experience is part of what makes them experts.
Consequently, you'll find recurring patterns of classes and
communicating objects in many object-oriented systems. These patterns
solve specific design problems and make object-oriented designs more
flexible, elegant, and ultimately reusable. They help designers reuse
successful designs by basing new designs on prior experience. A
designer who is familiar with such patterns can apply them immediately
to design problems without having to rediscover them.</P>
<A NAME="macbeth"></A>
<P>An analogy will help illustrate the point. Novelists and playwrights
rarely design their plots from scratch. Instead, they follow patterns
like "Tragically Flawed Hero" (Macbeth, Hamlet, etc.) or "The
Romantic Novel" (countless romance novels). In the same way,
object-oriented designers follow patterns like "represent states with
objects" and "decorate objects so you can easily add/remove
features." Once you know the pattern, a lot of design decisions
follow automatically.</P>
<A NAME="deja-vu"></A>
<P>We all know the value of design experience. How many times have you
had design <EM>déjà-vu</EM>—that feeling that you've solved a
problem before but not knowing exactly where or how? If you could
remember the details of the previous problem and how you solved it,
then you could reuse the experience instead of rediscovering it.
However, we don't do a good job of recording experience in
software design for others to use.</P>
<A NAME="auto1002"></A>
<P>The purpose of this book is to record experience in designing
object-oriented software as <a href="chapAfs-1.htm#designpattern" tppabs="http://ultra/development/DesignPatterns/lowres/chapAfs.htm#designpattern" target="_mainDisplayFrame">design patterns</A>. Each design
pattern systematically names, explains, and evaluates an important and
recurring design in object-oriented systems. Our goal is to capture
design experience in a form that people can use effectively. To this
end we have documented some of the most important design patterns and
present them as a catalog.</P>
<A NAME="auto1003"></A>
<P>Design patterns make it easier to reuse successful designs and
architectures. Expressing proven techniques as design patterns makes
them more accessible to developers of new systems. Design patterns
help you choose design alternatives that make a system reusable and
avoid alternatives that compromise reusability. Design patterns can
even improve the documentation and maintenance of existing systems by
furnishing an explicit specification of class and object interactions
and their underlying intent. Put simply, design patterns help a
designer get a design "right" faster.</P>
<A NAME="auto1004"></A>
<P>None of the design patterns in this book describes new or unproven
designs. We have included only designs that have been applied more
than once in different systems. Most of these designs have never been
documented before. They are either part of the folklore of the
object-oriented community or are elements of some successful
object-oriented systems—neither of which is easy for novice
designers to learn from. So although these designs aren't new, we
capture them in a new and accessible way: as a catalog of design
patterns having a consistent format.</P>
<A NAME="auto1005"></A>
<P>Despite the book's size, the design patterns in it capture only a
fraction of what an expert might know. It doesn't have any patterns
dealing with concurrency or distributed programming or real-time
programming. It doesn't have any application domain-specific
patterns. It doesn't tell you how to build user interfaces, how to
write device drivers, or how to use an object-oriented database. Each
of these areas has its own patterns, and it would be worthwhile for
someone to catalog those too.</P>
<A NAME="sec1-1"></A>
<H2><A HREF="#sec1-2"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next: Design Patterns in Smalltalk MVC"></A>
What is a Design Pattern?</H2>
<A NAME="auto1006"></A>
<P>Christopher Alexander says, "Each pattern describes a problem
which occurs over and over again in our environment, and then
describes the core of the solution to that problem, in such a way
that you can use this solution a million times over, without ever
doing it the same way twice" [<a href="bibfs-1.htm#Alexander_pl" tppabs="http://ultra/development/DesignPatterns/lowres/bibfs.htm#Alexander_pl" target="_mainDisplayFrame">AIS+77</A>, page <EM>x</EM>]. Even
though Alexander was talking about patterns in buildings and towns,
what he says is true about object-oriented design patterns. Our
solutions are expressed in terms of objects and interfaces instead
of walls and doors, but at the core of both kinds of patterns is
a solution to a problem in a context.</P>
<A NAME="despatt-essential"></A>
<P>In general, a pattern has four essential elements:</P>
<OL>
<A NAME="auto1007"></A>
<LI>The <STRONG>pattern name</STRONG>
is a handle we can use to describe a design problem, its solutions,
and consequences in a word or two. Naming a pattern immediately
increases our design vocabulary. It lets us design at a higher level
of abstraction. Having a vocabulary for patterns lets us talk about
them with our colleagues, in our documentation, and even to ourselves.
It makes it easier to think about designs and to communicate them and
their trade-offs to others. Finding good names has been one of the
hardest parts of developing our catalog.</LI>
<A NAME="auto1008"></A>
<P></P>
<A NAME="auto1009"></A>
<LI>The <STRONG>problem</STRONG>
describes when to apply the pattern. It explains the problem and its
context. It might describe specific design problems such as how to
represent algorithms as objects. It might describe class or object
structures that are symptomatic of an inflexible design. Sometimes
the problem will include a list of conditions that must be met before
it makes sense to apply the pattern.</LI>
<A NAME="auto1010"></A>
<P></P>
<A NAME="auto1011"></A>
<LI>The <STRONG>solution</STRONG>
describes the elements that make up the design, their relationships,
responsibilities, and collaborations. The solution doesn't describe a
particular concrete design or implementation, because a pattern is
like a template that can be applied in many different situations.
Instead, the pattern provides an abstract description of a design
problem and how a general arrangement of elements (classes and objects
in our case) solves it.</LI>
<A NAME="auto1012"></A>
<P></P>
<A NAME="auto1013"></A>
<LI>The <STRONG>consequences</STRONG>
are the results and trade-offs of applying the pattern. Though
consequences are often unvoiced when we describe design decisions,
they are critical for evaluating design alternatives and for
understanding the costs and benefits of applying the pattern.
The consequences for software often concern space and time trade-offs.
They may address language and implementation issues as well. Since
reuse is often a factor in object-oriented design, the consequences of
a pattern include its impact on a system's flexibility, extensibility,
or portability. Listing these consequences explicitly helps you
understand and evaluate them.</LI>
</OL>
<A NAME="auto1014"></A>
<P>Point of view affects one's interpretation of what is and isn't a
pattern. One person's pattern can be another person's primitive
building block. For this book we have concentrated on patterns at a
certain level of abstraction. <EM>Design patterns</EM> are not about
designs such as linked lists and hash tables that can be encoded in
classes and reused as is. Nor are they complex, domain-specific
designs for an entire application or subsystem. The design patterns
in this book are <EM>descriptions of communicating objects and
classes that are customized to solve a general design problem in a
particular context</EM>.</P>
<A NAME="auto1015"></A>
<P>A design pattern names, abstracts, and identifies the key aspects of a
common design structure that make it useful for creating a reusable
object-oriented design. The design pattern identifies the
participating classes and instances, their roles and collaborations,
and the distribution of responsibilities. Each design pattern focuses
on a particular object-oriented design problem or issue. It describes
when it applies, whether it can be applied in view of other design
constraints, and the consequences and trade-offs of its use. Since we
must eventually implement our designs, a design pattern also provides
sample C++ and (sometimes) Smalltalk code to illustrate an
implementation.</P>
<A NAME="ada"></A>
<A NAME="dylan"></A>
<A NAME="pascal"></A>
<A NAME="self"></A>
<P>Although design patterns describe object-oriented designs, they are
based on practical solutions that have been implemented in mainstream
object-oriented programming languages like Smalltalk and C++ rather
than procedural languages (Pascal, C, Ada) or more dynamic
object-oriented languages (CLOS, Dylan, Self). We chose Smalltalk and
C++ for pragmatic reasons: Our day-to-day experience has been in these
languages, and they are increasingly popular.</P>
<A NAME="auto1016"></A>
<P>The choice of programming language is important because it
influences one's point of view. Our patterns assume Smalltalk/C++-level
language features, and that choice determines what can and cannot
be implemented easily. If we assumed procedural languages, we
might have included design patterns called "Inheritance,"
"Encapsulation," and "Polymorphism." Similarly, some of our patterns
are supported directly by the less common object-oriented languages.
CLOS has multi-methods, for example, which lessen the need for a
pattern such as <A HREF="pat5kfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5kfs.htm"
TARGET="_mainDisplayFrame">Visitor (page 331)</A>. In fact, there
are enough differences between Smalltalk and C++ to mean that some
patterns can be expressed more easily in one language than the
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -