View
23
Download
0
Category
Preview:
DESCRIPTION
On Design Patterns An Illuminating Distinction By…. Mark Jason Dominus mjd-perl-yak+@plover.com http://perl.plover.com/yak/design/ ------------------ - PowerPoint PPT Presentation
Citation preview
rick.dove@stevens.edu, attributed copies permitted 1
Mark Jason Dominus
mjd-perl-yak+@plover.com http://perl.plover.com/yak/design/
------------------
Ignore the fact that he is concerned with the misinterpretation of design patterns in the domain of Software Systems –
consider that simply a foil to ground the discussion
On Design Patterns
An Illuminating Distinction By…
rick.dove@stevens.edu, attributed copies permitted 2
Software entities are more complex for their size than perhaps any other human construct because no two parts are alike. If they are, we make the two similar parts into a subroutine -- open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
Fred Brooks, Jr.
Value and Controversy
rick.dove@stevens.edu, attributed copies permitted 3
The "design patterns" movement in software claims to have been inspired by the works of architect Christopher Alexander. But an examination of Alexander's books reveals that he was actually talking about something much more interesting.Readers are cautioned that these slides were not originally intended for distribution on the web; they were written to accompany a five minute long talk given at Yet Another Perl Conference. They should not, therefore, be taken as a complete or well-reasoned presentation of my thoughts on this matter.
"Design Patterns" Aren't
Mark Jason Dominus - mjd-perl-yak+@plover.com - http://perl.plover.com/yak/design/
Mark Jason Dominus - mjd-perl-yak+@plover.com - http://perl.plover.com/yak/design/
rick.dove@stevens.edu, attributed copies permitted 4
Christopher Alexander
•Alexander is an architect•His books inspired the "Design Patterns" movement
o In particular, A Pattern Language (1979)o Alexander is a geniuso The book is a work of genius
8
rick.dove@stevens.edu, attributed copies permitted 5
What's It About?
•Alexander is trying to solve a central problem of architectural design•Suppose you want to design a college campus•You must delegate some of the design to the students and professors
o Otherwise, the Physics building won't work well for the physics people
o Architects don’t know enough about what physics people need,to do it all themselves
•But you can't delegate the design of every room to its occupantso Because then you will get a giant pile of rubble
9
rick.dove@stevens.edu, attributed copies permitted 6
• The problem Alexander is trying to solve is:
How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?
continued...
10
rick.dove@stevens.edu, attributed copies permitted 7
• The problem Alexander is trying to solve is:
How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?
• This is also a fundamental problem of computer systems development
10
rick.dove@stevens.edu, attributed copies permitted 8
Pattern Languages•Alexander suggests using Pattern Languages•A dictionary of terms laying out a set of basic design decisions
Alexander presents over 250 examples, including:
'alcoves' 'entrance transition' 'ceiling height variety' 'secret place' 'cascade of roofs' 'wings of light'
'something roughly in the middle'
•Design discussions are conducted using this language•Design at all levels springs from this common base
o Not every room will have 'alcoves' or 'ceiling height variety'
o Many will•The common language promotes commonality of design
11
rick.dove@stevens.edu, attributed copies permitted 9
Patterns vs. "Patterns"
•The pattern language does not tell you how to design anything•It helps you decide what should be designed•You get to make up whatever patterns you think will lead to good designs
continued...
12
rick.dove@stevens.edu, attributed copies permitted 10
Patterns vs. "Patterns"
•The pattern language does not tell you how to design anything•It helps you decide what should be designed•You get to make up whatever patterns you think will lead to good designs•The Gang-of-Four idea is to discover existing patterns of software development
o Then program people to implement them habituallyo Not the same thing at allo Much less profound
continued...
12
rick.dove@stevens.edu, attributed copies permitted 11
End Here
…for General Pattern Discussion
rick.dove@stevens.edu, attributed copies permitted 12
Patterns vs. "Patterns"
•The pattern language does not tell you how to design anything•It helps you decide what should be designed•You get to make up whatever patterns you think will lead to good designs•The Gang-of-Four idea is to discover existing patterns of software development
o Then program people to implement them habituallyo Not the same thing at allo Much less profoundo Also much less human
12
rick.dove@stevens.edu, attributed copies permitted 13
We're Missing Out
•I think Alexander's idea is tremendous•Computer programming might benefit from this tremendous idea
continued...
13
rick.dove@stevens.edu, attributed copies permitted 14
We're Missing Out
•I think Alexander's idea is tremendous•Computer programming might benefit from this tremendous idea•But the Gang-of-Four idea is obstructing its niche•Everyone already knows that "Design Patterns" means a library of C++ code templates
continued...
13
rick.dove@stevens.edu, attributed copies permitted 15
We're Missing Out
•I think Alexander's idea is tremendous•Computer programming might benefit from this tremendous idea•But the Gang-of-Four idea is obstructing its niche•Everyone already knows that "Design Patterns" means a library of C++ code templates
We need to take a fresh look at Christopher Alexander
•Thank you.
13
rick.dove@stevens.edu, attributed copies permitted 16
PostscriptSome people seem to have missed the point of this talk.
I am not saying "design patterns" are a bad idea. GoF-style design patterns seem to me to be an interesting and valuable idea, worth studying and developing. Even in their least interesting form, people do need to work around the severe deficiencies of C++, and if "design patterns" help them do that, it's a good thing.
My only major complaint is about the name. My talk points out that there is this other, different idea, that goes by almost the same name. Because it has almost the same name, the programming community is not paying attention to it---they think they are, but they are mistaken. That is a shame, because I think it is a really good idea---one that is potentially much more powerful and valuable than "design patterns".
So here again is the one-sentence summary of the only important point of my talk:
We need to take a fresh look at Christopher Alexander.
That's all I'm saying.
Thanks again for your interest.
rick.dove@stevens.edu, attributed copies permitted 17
PostscriptI was dreading the righteous wrath of the Design Patterns community. And I felt I would deserve anything I got for having associated their movement, however peripherally, with goat dick.
But what I have gotten has been much better than I expected or deserved. The comments I have seen on people's weblogs and have received by email have been universally thoughtful, polite, and insightful. I am sheepish but pleased. I did not expect this silly talk to generate any valuable discussion, but it has, and the credit should go to everyone but me.
My grateful thanks to everyone who has written in with ideas and discussion.
Eric Albert
Mike Gunderloy
IWETHEY board
Paul Kulchenko and Paul Kulchenko again
Peter Lindberg and Peter Lindberg again
Patrick Logan
Brett Morgan
Gordon Weakliem
Thomas Wagner
John Wiseman
rick.dove@stevens.edu, attributed copies permitted 18
Addendum (20021105)It appears to me that almost everyone who has read this has completely missed the point, even though I said it twice in big letters. People keep sending me mail that says things like this: “I'm afraid you got it all backwards. At least the iterator example is totally flawed.” Or people spend a lot of time arguing about how foreach is not analogous to an iterator pattern, or how it doesn't do the same thing, or how even if it does, … blah blah blah. None of this has anything to do what the point of my talk. I really wish I'd left out the thing about the iterator pattern.
Why do people focus on pages 4, 5, and 6 of a 13-page talk, and forget all about slides 8, 9, 10, 11, 12, and 13, where I make the real point?
Another theory is that some of these folks have allied themselves with the Tribe of the Pattern, so anything that appears to be an attack on patterns, or critical of patterns, or which even says anything critical (say, criticizing C++'s crapulent macro system) in a context that discusses patterns, becomes a personal attack on them, and they have to defend themselves against it. Since most of these people haven't read the Alexander book, they can't possibly argue with my point. But they know about iterators, so they argue with me about that.
The point of the talk is this: The "design patterns" you get from the Gang-of-Four book are not the same as the idea of "design patterns" that are put forward in Alexander's books. People say they are, but they aren't the same thing. Alexander's idea is a really good one, one that programmers might find useful. But very few programmers are going to find out about it, because they think they already know what it is. But they actually know this other idea which happens to go by the same name.
So (once again) we need to take a fresh look at Christopher Alexander.
Forget what I said about the damn iterator pattern, already.
rick.dove@stevens.edu, attributed copies permitted 19
The rest of the slides that follow were moved from the beginning of this presentation to here because they are not Germaine to a “general” discussion on patterns and too specific on “programming” code patterns
rick.dove@stevens.edu, attributed copies permitted 20
"Design Patterns" Aren'tM. J. Dominus
Plover Systems Co.mjd-yapc-patterns-@plover.com
June, 2002
1
rick.dove@stevens.edu, attributed copies permitted 21
Design Patterns
•A big trend in the past few years •Spearheaded by the "Gang of Four" ------------->•Also Pattern Languages of Program Design (Coplien & Schmidt)•And many others on the same bandwagon
2
rick.dove@stevens.edu, attributed copies permitted 22
What is a Pattern?
•An 'element of reusable software‘
A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context. •(Gamma et al., emphasis mine.)
3
rick.dove@stevens.edu, attributed copies permitted 23
For Example: The iterator Pattern
•You have a collection object•You want to iterate over the elements of the collection •Without exposing any internals•To do this, you get out the Design Patterns book •You build an iterator class the way it says•Using the sample C++ code provided
continued...
4
rick.dove@stevens.edu, attributed copies permitted 24
Is this really "a recurring design problem"?
•In C++ it is, because C++ sucks (ditto Java)•But in a better language, it's not a problem at all•For example, Perl provides a universal solution:
continued...
5
rick.dove@stevens.edu, attributed copies permitted 25
Is this really "a recurring design problem"?
•In C++ it is, because C++ sucks (ditto Java)•But in a better language, it's not a problem at all•For example, Perl provides a universal solution:
foreach $element (@collection) { ... } •This fails in C++ because the type system is too weak•Solutions with higher-order functions fail too
o No anonymous functions or lexical closure•Ditto Java
5
rick.dove@stevens.edu, attributed copies permitted 26
Is this really "a recurring design problem“?
•Other good solutions to this problem include a good macro system
(defmacro dotimes ((var limit) &body forms) `(maptimes #'(lambda (,var) ,@forms) ,limit))
continued...
6
rick.dove@stevens.edu, attributed copies permitted 27
Is this really "a recurring design problem“?
•Other good solutions to this problem include a good macro system
(defmacro dotimes ((var limit) &body forms) `(maptimes #'(lambda (,var) ,@forms) ,limit))
•But the C++ macro system blows goat dick
6
rick.dove@stevens.edu, attributed copies permitted 28
The Outcome?
•The C++ programmer gets to paste in code from Design Patternso Ten timeso Or a hundred times
•People are using 1970s-era languages•The "Design Patterns" solution is to turn the programmer into a fancy macro processor
7
Recommended