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