Transcript Design Patterns

On Design Patterns
An Illuminating Distinction By…
Mark Jason Dominus
[email protected] 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
[email protected], attributed copies permitted
1
Value and Controversy
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.
[email protected], attributed copies permitted
2
"Design Patterns" Aren't
Mark Jason Dominus - [email protected] - http://perl.plover.com/yak/design/
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.
Mark Jason Dominus - [email protected] - http://perl.plover.com/yak/design/
[email protected], attributed copies permitted
3
8
Christopher Alexander
•
•
Alexander is an architect
His books inspired the
"Design Patterns" movement
o In particular, A Pattern Language (1979)
o Alexander is a genius
o The book is a work of genius
[email protected], attributed copies permitted
4
9
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 occupants
o Because then you will get a giant pile of rubble
[email protected], attributed copies permitted
5
10
•
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...
[email protected], attributed copies permitted
6
10
•
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
[email protected], attributed copies permitted
7
11
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
[email protected], attributed copies permitted
8
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
continued...
[email protected], attributed copies permitted
9
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 habitually
o Not the same thing at all
o Much less profound
continued...
[email protected], attributed copies permitted
10
End Here
…for General Pattern Discussion
[email protected], attributed copies permitted
11
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 habitually
o Not the same thing at all
o Much less profound
o Also much less human
[email protected], attributed copies permitted
12
13
We're Missing Out
•
•
I think Alexander's idea is tremendous
Computer programming might benefit from this tremendous idea
continued...
[email protected], attributed copies permitted
13
13
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...
[email protected], attributed copies permitted
14
13
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.
[email protected], attributed copies permitted
15
Postscript
Some 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.
[email protected], attributed copies permitted
16
Postscript
I 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
[email protected], attributed copies permitted
17
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.
[email protected], attributed copies permitted
18
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
[email protected], attributed copies permitted
19
1
"Design Patterns" Aren't
M. J. Dominus
Plover Systems Co.
[email protected]
June, 2002
[email protected], attributed copies permitted
20
2
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
[email protected], attributed copies permitted
21
3
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.)
[email protected], attributed copies permitted
22
4
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...
[email protected], attributed copies permitted
23
5
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...
[email protected], attributed copies permitted
24
5
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
[email protected], attributed copies permitted
25
6
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...
[email protected], attributed copies permitted
26
6
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
[email protected], attributed copies permitted
27
7
The Outcome?
•
•
•
The C++ programmer gets to paste in code from Design Patterns
o Ten times
o Or a hundred times
People are using 1970s-era languages
The "Design Patterns" solution is to
turn the programmer into a fancy
macro processor
[email protected], attributed copies permitted
28