📄 sect02.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<!--
This document was converted from RTF source:
By rtftohtml 4.19
See http://www.sunpack.com/RTF
Filename:TIPython.rtf
Application Directory:c:\tools\rtf2html\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:12/31/2001
Translation Time:08:24:11
Translation Platform:Win32
Number of Output files:18
This File:Sect02.htm
SplitDepth=1
SkipNavPanel=1
SkipLeadingToc=1
SkipTrailingToc=1
GenContents=1
GenFrames=1
GenIndex=1
-->
<HEAD lang="en"><META http-equiv="Content-Type" content="text/html">
<TITLE>The pattern concept</TITLE>
<script language="JavaScript">
</script>
</head>
<BODY BGCOLOR="#FFFFFF"><DIV ALIGN="CENTER">
<a href="http://www.MindView.net">
<img src="mindview.gif" alt="MindView Inc." BORDER = "0"></a>
<CENTER>
<FONT FACE="Verdana, Tahoma, Arial, Helvetica, Sans" size = "-1">
<!-- [ <a href="README.txt">Viewing Hints</a> ]
[ <a href="RevisionHistory.htm">Revision History</a> ] -->
[ <a href="http://www.mindview.net/Books/TIPython/">Book Home Page</a> ]
[ <a href="http://www.mindview.net/Etc/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/Seminars">Seminars</a> ]
[ <a href="http://www.mindview.net/CDs">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/Services">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana, Tahoma, Arial, Helvetica, Sans">
Thinking in Python<br>
<small>Revision 0.1.2 (12/31/01) -- Incomplete and Unfinished</small></FONT></H2>
<H3><FONT FACE="Verdana, Tahoma, Arial, Helvetica, Sans">
by Bruce Eckel ©2002 MindView, Inc.</FONT></H3>
<FONT FACE="Verdana, Tahoma, Arial, Helvetica, Sans" size = "-1">
[ <a href="Sect01.htm">Previous Chapter</a> ]
[ <a href="javascript:window.location.href = 'Index.htm';">Table of Contents</a> ]
[ <a href="DocIdx.htm">Index</a> ]
[ <a href="Sect03.htm">Next Chapter</a> ]
</FONT>
</CENTER>
</P></DIV><A NAME="_Toc534420062"></A><A NAME="Heading12"></A><FONT FACE = "Verdana, Tahoma, Arial, Helvetica, Sans"><H1 ALIGN="LEFT">
The pattern concept</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia" SIZE=4>“Design patterns help you
learn from others' successes instead of your own
failures</FONT><A NAME="fnB3" HREF="#fn3">[3]</A><FONT FACE="Georgia" SIZE=4>.”
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_16">Add Comment</A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Probably the most important step forward
in object-oriented design is the “design patterns” movement,
chronicled in <A NAME="Index1"></A><A NAME="Index2"></A><I>Design Patterns
(ibid)</I></FONT><A NAME="fnB4" HREF="#fn4">[4]</A><FONT FACE="Georgia">. That
book shows 23 different solutions to particular classes of problems. In this
book, the basic concepts of design patterns will be introduced along with
examples. This should whet your appetite to read <I>Design Patterns</I> by
Gamma, et. al., a source of what has now become an essential, almost mandatory,
vocabulary for OOP programmers.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_17">Add Comment</A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The latter part of this book contains an
example of the design evolution process, starting with an initial solution and
moving through the logic and process of evolving the solution to more
appropriate designs. The program shown (a trash sorting simulation) has evolved
over time, and you can look at that evolution as a prototype for the way your
own design can start as an adequate solution to a particular problem and evolve
into a flexible approach to a class of problems.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_18">Add Comment</A></FONT><A NAME="_Toc534420063"></A><BR></P></DIV>
<A NAME="Heading13"></A><FONT FACE = "Verdana, Tahoma, Arial, Helvetica, Sans"><H2 ALIGN="LEFT">
What is a pattern?</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Initially, you can think of a pattern as
an especially clever and insightful way of solving a particular class of
problems. That is, it looks like a lot of people have worked out all the angles
of a problem and have come up with the most general, flexible solution for it.
The problem could be one you have seen and solved before, but your solution
probably didn’t have the kind of completeness you’ll see embodied in
a pattern.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_19">Add Comment</A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Although they’re called
“design patterns,” they really aren’t tied to the realm of
design. A pattern seems to stand apart from the traditional way of thinking
about analysis, design, and implementation. Instead, a pattern embodies a
complete idea within a program, and thus it can sometimes appear at the analysis
phase or high-level design phase. This is interesting because a pattern has a
direct implementation in code and so you might not expect it to show up before
low-level design or implementation (and in fact you might not realize that you
need a particular pattern until you get to those phases).
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_20">Add Comment</A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The basic concept of a pattern can also
be seen as the basic concept of program design: adding a layer of
<A NAME="Index3"></A><A NAME="Index4"></A>abstraction. Whenever you abstract
something you’re isolating particular details, and one of the most
compelling motivations behind this is to <I>separate things that change from
things that stay the same</I>. Another way to put this is that once you find
some part of your program that’s likely to change for one reason or
another, you’ll want to keep those changes from propagating other changes
throughout your code. Not only does this make the code much cheaper to maintain,
but it also turns out that it is usually simpler to understand (which results in
lowered costs).
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_21">Add Comment</A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Often, the most difficult part of
developing an elegant and cheap-to-maintain design is in discovering what I call
“the <A NAME="Index5"></A><A NAME="Index6"></A><A NAME="Index7"></A>vector
of change.” (Here, “vector” refers to the maximum gradient and
not a container class.) This means finding the most important thing that changes
in your system, or put another way, discovering where your greatest cost is.
Once you discover the vector of change, you have the focal point around which to
structure your design.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_22">Add Comment</A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">So the goal of design patterns is to
isolate changes in your code. If you look at it this way, you’ve been
seeing some design patterns already in this book. For example,
<A NAME="Index8"></A>inheritance can be thought of as a design pattern (albeit
one implemented by the compiler). It allows you to express differences in
behavior (that’s the thing that changes) in objects that all have the same
interface (that’s what stays the same). <A NAME="Index9"></A>Composition
can also be considered a pattern, since it allows you to
change—dynamically or statically—the objects that implement your
class, and thus the way that class works.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_23">Add Comment</A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Another pattern that appears in <I>Design
Patterns</I> is the <A NAME="Index10"></A><I>iterator</I>, which has been
implicitly available in <B>for</B> loops from the beginning of the language, and
was introduced as an explicit feature in Python 2.2. An iterator allows you to
hide the particular implementation of the container as you’re stepping
through and selecting the elements one by one. Thus, you can write generic code
that performs an operation on all of the elements in a sequence without regard
to the way that sequence is built. Thus your generic code can be used with any
object that can produce an iterator.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_24">Add Comment</A></FONT><A NAME="_Toc534420064"></A><BR></P></DIV>
<A NAME="Heading14"></A><FONT FACE = "Verdana, Tahoma, Arial, Helvetica, Sans"><H2 ALIGN="LEFT">
Pattern taxonomy</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">One of the events that’s occurred
with the rise of design patterns is what could be thought of as the
“pollution” of the term – people have begun to use the term to
mean just about anything synonymous with “good.” After some
pondering, I’ve come up with a sort of hierarchy describing a succession
of different types of categories:
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_25">Add Comment</A></FONT><BR></P></DIV>
<OL>
<LI><FONT FACE="Georgia"><B></B>how we write code in a particular language to do
this particular type of thing. This could be something as common as the way that
you code the process of stepping through an array in C (and not running off the
end).
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_26">Add Comment</A></FONT><LI><FONT FACE="Georgia"><B>Design</B>:
the solution that we came up with to solve this particular problem. This might
be a clever design, but it makes no attempt to be general.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_27">Add Comment</A></FONT><LI><FONT FACE="Georgia"><B>Design</B>:
a way to solve this <I>kind</I> of problem. A design that has become more
general, typically through reuse.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_28">Add Comment</A></FONT><LI><FONT FACE="Georgia"><B>Pattern</B>:
how to solve an entire class of similar problem. This usually only appears after
applying a standard design a number of times, and then seeing a common pattern
throughout these applications.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_29">Add Comment</A></FONT></OL><DIV ALIGN="LEFT"><P><FONT FACE="Georgia">I
feel this helps put things in perspective, and to show where something might
fit. However, it doesn’t say that one is better than another. It
doesn’t make sense to try to take every problem solution and generalize it
to a design pattern – it’s not a good use of your time, and you
can’t force the discovery of patterns that way; they tend to be subtle and
appear over time.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_30">Add Comment</A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">One could also argue for the inclusion of
<I>Analysis Pattern</I> and <I>Architectural Pattern</I> in this taxonomy.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_31">Add Comment</A></FONT><A NAME="_Toc476705894"></A><A NAME="_Toc534420065"></A><BR></P></DIV>
<A NAME="Heading15"></A><FONT FACE = "Verdana, Tahoma, Arial, Helvetica, Sans"><H2 ALIGN="LEFT">
Design Structures</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">One of the struggles that I’ve had
with design patterns is their classification – I’ve often found the
GoF approach to be too obscure, and not always very helpful. Certainly, the
<I>Creational</I> patterns are fairly straightforward: how are you going to
create your objects? This is a question you normally need to ask, and the name
brings you right to that group of patterns. But I find <I>Structural</I> and
<I>Behavioral</I> to be far less useful distinctions. I have not been able to
look at a problem and say “clearly, you need a structural pattern
here,” so that classification doesn’t lead me to a solution
(I’ll readily admit that I may be missing something here).
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_32">Add Comment</A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">I’ve labored for awhile with this
problem, first noting that the underlying structure of some of the GoF patterns
are similar to each other, and trying to develop relationships based on that
similarity. While this was an interesting experiment, I don’t think it
produced much of use in the end because the point is to solve problems, so a
helpful approach will look at the problem to solve and try to find relationships
between the problem and potential solutions.
<A HREF="http://www.mindview.net/Books/TIPython/BackTalk/FindPage/A_33">Add Comment</A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">To that end, I’ve begun to try to
collect basic design structures, and to try to see if there’s a way to
relate those structures to the various design patterns that appear in well
thought-out systems. Currently, I’m just trying to make a list, but
eventually I hope to make steps towards connecting these structures with
patterns (or I may come up with a different approach altogether – this is
still in its formative stages).
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -