On Design Patterns An Illuminating Distinction By…

1. On Design PatternsAn Illuminating Distinction By… Mark Jason Dominus mjd-perl-yak+@plover.comhttp://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

2. 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.

3. "Design Patterns" Aren't Mark Jason Dominus - mjd-perl-yak+@plover.com - 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 - mjd-perl-yak+@plover.com - http://perl.plover.com/yak/design/

4. 8 Christopher Alexander • Alexander is an architect • His books inspired the "Design Patterns" movement • In particular, A Pattern Language (1979) • Alexander is a genius • The book is a work of genius

5. 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 • Otherwise, the Physics building won't work well for the physics people • 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 • Because then you will get a giant pile of rubble

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? continued...

7. 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

8. 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 • Not every room will have 'alcoves' or 'ceiling height variety' • Many will • The common language promotes commonality of design

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 continued...

10. 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 • Then program people to implement them habitually • Not the same thing at all • Much less profound continued...

11. End Here…for General Pattern Discussion

12. 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 • Then program people to implement them habitually • Not the same thing at all • Much less profound • Also much less human

13. 13 We're Missing Out • I think Alexander's idea is tremendous • Computer programming might benefit from this tremendous idea continued...

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 continued...

15. 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.

16. 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.

17. 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

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.

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

20. 1 "Design Patterns" Aren't M. J. Dominus Plover Systems Co. mjd-yapc-patterns-@plover.com June, 2002

21. 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

22. 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.)

23. 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...

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: continued...

25. 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 • No anonymous functions or lexical closure • Ditto Java

26. 6 • Is this really "a recurring design problem“? • Other good solutions to this problem include a good macro system • (defmacrodotimes ((var limit) &body forms) `(maptimes #'(lambda (,var) ,@forms) ,limit)) • continued...

27. 6 • Is this really "a recurring design problem“? • Other good solutions to this problem include a good macro system • (defmacrodotimes ((var limit) &body forms) `(maptimes #'(lambda (,var) ,@forms) ,limit)) • But the C++ macro system blows goat dick

28. 7 The Outcome? • The C++ programmer gets to paste in code from Design Patterns • Ten times • Or a hundred times • People are using 1970s-era languages • The "Design Patterns" solution is to turn the programmer into a fancy macro processor