8 ms·

Design patterns aren't

69 points by henning 15y ago

r00fus 15y ago
DSL FTW? The article/presentation seems to imply the benefit of domain-specific languages for capturing the software requirements (which is what Alexander's "Pattern Languages" sounds like to me). How to properly create and re-use DSLs sounds very much like an artform to me...
- yxhuvud 15y ago
  I thought of that as well, but the reach of the idea goes a long way past DSLs. It definitely applies to programming language construction in general and to almost anything you can do with computers. Find the right abstractions that gives you the right amount of details while at the same time give you the tools to scale your reasoning about a problem, and you can move mountains. Find the wrong balance, and you will end up with a cluttery hell that is impossible to maintain or a blunt tool that doesn't do anything well.
eropple 15y ago
paraphrased: "In C++/Java, you write an iterator again and again for every collection" No, you don't. If you write them yourselves (which is in most but all cases the wrong approach, what with the Java libraries and the C++ STL), you use templates or generics, as appropriate, to define reusable ones. In many cases, proper patterns are reusable--and in many cases for good programmers, design patterns occur automatically just because they're a logical way to do something. I don't set out to create flyweight objects, they're the simplest way to achieve my goal. I don't write a thread pool just to create a thread pool, I write a thread pool because it makes sense. Even in 2002, this was the case. I don't get the feeling that the author of these slides knew either well enough to make the claims he made. . The Gang-of-Four idea is to discover existing patterns of software development / Then program people to implement them habitually Er...no. The book Design Patterns is descriptive, not prescriptive. Is that so hard to get? . I am by no means a C++ fan, or even really a GoF fan, but this post is slagging it just to slag it. If you want to slag it after you understand it, by all means (and I have perturbed a great many electrons in doing so, myself), but it doesn't sound like the author does, at all.
- nagnatron 15y ago
  Have you read anything by Alexander?
  - eropple 15y ago
    I haven't, but I'm not looking at what he says. I'm looking at what appears to be the author of these slides, taking a very strong point about something about which he demonstrates little knowledge. No, the GoF stuff isn't the same as what (it seems like) Alexander is saying. That doesn't make it wrong, and it doesn't mean this author isn't misrepresenting the GoF in the linked work. The GoF, are not the Design Pattern Police, demanding that you tack Strategy and Command and Memento objects everywhere. It's observational material based on seeing many people reinvent essentially the same wheel over and over again.
    - loup-vaillant 15y ago
      http://perl.plover.com/yak/design/samples/note.html http://perl.plover.com/yak/design/samples/note.html He didn't want to criticize the GoF book. He wanted to say that C++ and Java suck because they need Patterns. PG also said as much. Quote from the link above : > 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.
      - kenjackson 15y ago
        I don't understand how design patterns can't exist in any language. I'd even argue its the existence of design patterns that make programs readable at all. I can look at code and say, "ahh... case analysis."
        johnzabroski 15y ago
        I can look at code and say, "ah, Alan Perlis, you were right when I read your advice when I was 11 years old, but did not understand your wisdom [1]": 10. Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary. [1] http://www.cs.yale.edu/quotes.html http://www.cs.yale.edu/quotes.html
walexander 15y ago
I think the criticism here on GoF is misdirected. As far as I'm concerned, GoF is (or at least should be treated as) a taxonomy, not a cookbook. The fact that people use it as a cookbook is not necessarily the fault of the authors.
- eropple 15y ago
  Agreed. The GoF's stuff is descriptive, not prescriptive. You'll always get the occasional zealots going "no no, you must slather your code in Servants and Visitors", but...they're not the GoF, and who cares what they say?
- ap22213 15y ago
  The GoF value isn't in being a taxonomy. It's about noticing that given certain environmental conditions and a goal, people will derive similar solutions. Patterns are just time-savers. So, if you see X, then do Y, because it will just work. That's pretty much what Alexander's books say. The failure of GoF, in particular, is that people took it as a golden rule for every environment. IIRC, the examined source code was all object oriented c++ and smalltalk code. Yeah - it's not surprising that those patterns aren't going to work well in, say, Haskell.
  - teyc 15y ago
    | The failure of GoF, in particular, is that people took it as a golden rule for every environment +1 Back in the days of C when assembly was still important, calling conventions represented patterns that ensure the stack got cleaned up properly. We may no longer talk about it, it is still there, doing its work silently. The design patterns were harvested from a language that didn't support lisp-style macros or continuations or closures. Patterns are helpful for people who have to work with particular languages, but are not particularly useful to language designers. But then, they [language designers] already know that.
  - viraptor 15y ago
    True, they won't work everywhere that well. There's another presentation from Peter Norvig: http://norvig.com/design-patterns/ppframe.htm http://norvig.com/design-patterns/ppframe.htm It has a lot of examples which fold into one liners in dynamic languages or are simply "the way it could be done" instead of a pattern (they don't require additional code or attention - see abstract factory).
zzzeek 15y ago
I'd recommend going over the postscript http://perl.plover.com/yak/design/samples/note.html http://perl.plover.com/yak/design/samples/note.html and note that all the discussion here has already happened years ago. IMHO if the majority of listeners misunderstand your talk and don't get the point you're trying to make, then you made a bad talk. Seems like his real point was to distinguish between the GOF book and the Alexander book were about. That's great. Present that point in a thoughtful and careful way, not by going off on GOF in a way that will turn off listeners/readers and occlude the more subtle point you're trying to make.
- wnoise 15y ago
  Not the majority of his listeners but some hard to measure fraction of those who read his slides online without the context of the talk that he gave. Yeah, it's definitely not a good set of slides unconnected to the talk. He even admits that.
- jerf 15y ago
  "IMHO if the majority of listeners misunderstand your talk and don't get the point you're trying to make, then you made a bad talk." Does not follow. It is also possible that he has made a hard point, which the brains of the readers have a hard time representing with their internal conceptualizations, therefore misunderstand, then act on those misunderstandings. I think the presentation is perfectly clear, and do not see any obvious way it can be made wildly easier to understand. Quality of communication is not just bounded by the quality of the sender, it is bounded by the quality of the recipient as well. The point this presentation is trying to make is intrinsically hobbled by the fact that many people cognitively will only perceive something that boils down to "PATTERNS GOOD" (hooray!) or "PATTERNS BAD" (boo! flames!), and "PATTERNS DOGMA A LOSSY TRANSLATION OF SUPERIOR ORIGINAL PATTERNS CONCEPT" doesn't into either of those buckets very well (the distinction between patterns dogma and patterns idea being a tricky one all by itself), and if that's how one approaches it, it's easy to see how it simply falls into the "bad" bucket.
slavak 15y ago
In his postscript the author explains that he wasn't trying to criticize design patterns, but was rather trying to promote this other concept; which, supposedly, is little known in CS circles because of the similar names... His summary: "We need to take a fresh look at Christopher Alexander." That's all well and good, and as far as I know the concept of pattern languages could be very useful; I wouldn't know, I've never heard of it till today, and in fact still have no idea what it's about. Which brings me to my point, which is to wonder why the author chose to waste an entire 5 minute and 13 slide presentation (5 of which were dedicated just to bashing design patterns) to making the point that "we need to take a fresh look at Christopher Alexander," instead of, say, spending more time introducing Alexander's ideas and presenting ways they could be useful in our domain. I will conclude by pointing out another pet peeve of mine, which is sensationalist titles only tangentially related to the content. Design pattern, most certainly, ARE. What they are NOT is pattern languages, which is a similar sounding but entirely different concept. </ grumpy geezer mode>
- deleted 15y ago
  [deleted]
- DanielRibeiro 15y ago
  There was also a great discussion about this on Stack overflow: http://stackoverflow.com/questions/327955/does-functional-programming-replace-gof-design-patterns http://stackoverflow.com/questions/327955/does-functional-pr... TL;DR: Gof had in mind C++ and Smalltalk. Some languages eliminate the need for many of the patterns in GoF, and they don't eliminate the idioms (patterns for a particular language), as they barely cover it. Another good info on the subject is this presentation: http://www.infoq.com/presentations/Functional-Design-Patterns http://www.infoq.com/presentations/Functional-Design-Pattern...
ericbb 15y ago
Sounds like the Ubiquitous Language idea from Domain Driven Design is a closer analogue. I haven't read Christopher Alexander's book so I'm just going on the article's summary. http://domaindrivendesign.org/node/132 http://domaindrivendesign.org/node/132
aaimnr 15y ago
The critique of GoF presented is superficial. The main difference being GoF's 'how' against Alexander's 'what' doesn't come from GoF's misunderstanding of Alexander's original work. It comes from a different role of architecture of a building versus an architecture of a computer program. It's easier to say about Alexander's pattern that it provides an answer for a 'what' question because the building's architecture is something that people interact with directly with all their senses. Hence a pattern like "159. LIGHT ON TWO SIDES OF EVERY ROOM" ( http://www.patternlanguage.com/apl/aplsample/apl159/apl159.htm http://www.patternlanguage.com/apl/aplsample/apl159/apl159.h... ) seems like an end in itself when compared to eg. a iterator pattern, which obviously always will be described merely as a mean to some more general functionality of the application. The truth is, "LIGHT ON TWO SIDES OF EVERY ROOM" is also a mean - a mean to making a room more bright, pleasant and friendly . If it feels more substantial than an iterator pattern, it's just because we directly interact with an architecture of a building in contrast to the architecture of a software, which is always hidden. There's nothing wrong with GoF, it just follows from the essential quality of a computer software.
keithnoizu 15y ago
What, is this not how we've been using design patterns all along? I always used these patterns to simplify the explanation of how the architecture should or could work. I've never referred to some master cheat sheet of patterns I can copy and paste into my source code to save time, you generally need to custom fit your solutions to the problem at hand.
zwieback 15y ago
When I read the GoF book in '95 it was a revelation, I had learned C++ a few years earlier and here were all the things I had seen in my and other people's code with names and explanations. At the time Rogue Wave hosted an informal lunch meeting in our town where they and some OSU guys discussed patterns, I attended as a visitor and to me it just seemed magical. Over the years some of the high hopes have been dashed but I think some of the core pattern ideas have become useful standard idioms. A year or so after reading the GoF book I saw the Alexander book in a used book store and picked it up to see what it was all about and I was very surprised. I like the book a lot but I really don't think the parallels with the GoF book and the software design patterns are all that strong. The Alexander book does not seem very systematic or analytic, it's more rambling and philosophical. I'm not an architect so I probably don't see the big picture but to me the book seems to lack a coherent vision. If you're interested how Alexander himself saw himself fit into the emerging pattern movement, here's a link to James Coplien's description of Alexander's OOPSLA appearance in '96: https://sites.google.com/a/gertrudandcope.com/info/Publications/Oopsla96/feetofmaster-html https://sites.google.com/a/gertrudandcope.com/info/Publicati... Hard to believe it's been 15 years!

69 points by henning 15y ago

DSL FTW? The article/presentation seems to imply the benefit of domain-specific languages for capturing the software requirements (which is what Alexander's "Pattern Languages" sounds like to me). How to properly create and re-use DSLs sounds very much like an artform to me...

yxhuvud 15y ago
I thought of that as well, but the reach of the idea goes a long way past DSLs. It definitely applies to programming language construction in general and to almost anything you can do with computers. Find the right abstractions that gives you the right amount of details while at the same time give you the tools to scale your reasoning about a problem, and you can move mountains. Find the wrong balance, and you will end up with a cluttery hell that is impossible to maintain or a blunt tool that doesn't do anything well.

eropple 15y ago

paraphrased: "In C++/Java, you write an iterator again and again for every collection" No, you don't. If you write them yourselves (which is in most but all cases the wrong approach, what with the Java libraries and the C++ STL), you use templates or generics, as appropriate, to define reusable ones. In many cases, proper patterns are reusable--and in many cases for good programmers, design patterns occur automatically just because they're a logical way to do something. I don't set out to create flyweight objects, they're the simplest way to achieve my goal. I don't write a thread pool just to create a thread pool, I write a thread pool because it makes sense. Even in 2002, this was the case. I don't get the feeling that the author of these slides knew either well enough to make the claims he made. . The Gang-of-Four idea is to discover existing patterns of software development / Then program people to implement them habitually Er...no. The book Design Patterns is descriptive, not prescriptive. Is that so hard to get? . I am by no means a C++ fan, or even really a GoF fan, but this post is slagging it just to slag it. If you want to slag it after you understand it, by all means (and I have perturbed a great many electrons in doing so, myself), but it doesn't sound like the author does, at all.

nagnatron 15y ago
Have you read anything by Alexander?
- eropple 15y ago
  I haven't, but I'm not looking at what he says. I'm looking at what appears to be the author of these slides, taking a very strong point about something about which he demonstrates little knowledge. No, the GoF stuff isn't the same as what (it seems like) Alexander is saying. That doesn't make it wrong, and it doesn't mean this author isn't misrepresenting the GoF in the linked work. The GoF, are not the Design Pattern Police, demanding that you tack Strategy and Command and Memento objects everywhere. It's observational material based on seeing many people reinvent essentially the same wheel over and over again.
  - loup-vaillant 15y ago
    http://perl.plover.com/yak/design/samples/note.html http://perl.plover.com/yak/design/samples/note.html He didn't want to criticize the GoF book. He wanted to say that C++ and Java suck because they need Patterns. PG also said as much. Quote from the link above : > 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.
    - kenjackson 15y ago
      I don't understand how design patterns can't exist in any language. I'd even argue its the existence of design patterns that make programs readable at all. I can look at code and say, "ahh... case analysis."
      - johnzabroski 15y ago
        I can look at code and say, "ah, Alan Perlis, you were right when I read your advice when I was 11 years old, but did not understand your wisdom [1]": 10. Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary. [1] http://www.cs.yale.edu/quotes.html http://www.cs.yale.edu/quotes.html

walexander 15y ago

I think the criticism here on GoF is misdirected. As far as I'm concerned, GoF is (or at least should be treated as) a taxonomy, not a cookbook. The fact that people use it as a cookbook is not necessarily the fault of the authors.

eropple 15y ago
Agreed. The GoF's stuff is descriptive, not prescriptive. You'll always get the occasional zealots going "no no, you must slather your code in Servants and Visitors", but...they're not the GoF, and who cares what they say?
ap22213 15y ago
The GoF value isn't in being a taxonomy. It's about noticing that given certain environmental conditions and a goal, people will derive similar solutions. Patterns are just time-savers. So, if you see X, then do Y, because it will just work. That's pretty much what Alexander's books say. The failure of GoF, in particular, is that people took it as a golden rule for every environment. IIRC, the examined source code was all object oriented c++ and smalltalk code. Yeah - it's not surprising that those patterns aren't going to work well in, say, Haskell.
- teyc 15y ago
  | The failure of GoF, in particular, is that people took it as a golden rule for every environment +1 Back in the days of C when assembly was still important, calling conventions represented patterns that ensure the stack got cleaned up properly. We may no longer talk about it, it is still there, doing its work silently. The design patterns were harvested from a language that didn't support lisp-style macros or continuations or closures. Patterns are helpful for people who have to work with particular languages, but are not particularly useful to language designers. But then, they [language designers] already know that.
- viraptor 15y ago
  True, they won't work everywhere that well. There's another presentation from Peter Norvig: http://norvig.com/design-patterns/ppframe.htm http://norvig.com/design-patterns/ppframe.htm It has a lot of examples which fold into one liners in dynamic languages or are simply "the way it could be done" instead of a pattern (they don't require additional code or attention - see abstract factory).

zzzeek 15y ago

I'd recommend going over the postscript http://perl.plover.com/yak/design/samples/note.html http://perl.plover.com/yak/design/samples/note.html and note that all the discussion here has already happened years ago. IMHO if the majority of listeners misunderstand your talk and don't get the point you're trying to make, then you made a bad talk. Seems like his real point was to distinguish between the GOF book and the Alexander book were about. That's great. Present that point in a thoughtful and careful way, not by going off on GOF in a way that will turn off listeners/readers and occlude the more subtle point you're trying to make.

wnoise 15y ago
Not the majority of his listeners but some hard to measure fraction of those who read his slides online without the context of the talk that he gave. Yeah, it's definitely not a good set of slides unconnected to the talk. He even admits that.
jerf 15y ago
"IMHO if the majority of listeners misunderstand your talk and don't get the point you're trying to make, then you made a bad talk." Does not follow. It is also possible that he has made a hard point, which the brains of the readers have a hard time representing with their internal conceptualizations, therefore misunderstand, then act on those misunderstandings. I think the presentation is perfectly clear, and do not see any obvious way it can be made wildly easier to understand. Quality of communication is not just bounded by the quality of the sender, it is bounded by the quality of the recipient as well. The point this presentation is trying to make is intrinsically hobbled by the fact that many people cognitively will only perceive something that boils down to "PATTERNS GOOD" (hooray!) or "PATTERNS BAD" (boo! flames!), and "PATTERNS DOGMA A LOSSY TRANSLATION OF SUPERIOR ORIGINAL PATTERNS CONCEPT" doesn't into either of those buckets very well (the distinction between patterns dogma and patterns idea being a tricky one all by itself), and if that's how one approaches it, it's easy to see how it simply falls into the "bad" bucket.

slavak 15y ago

In his postscript the author explains that he wasn't trying to criticize design patterns, but was rather trying to promote this other concept; which, supposedly, is little known in CS circles because of the similar names... His summary: "We need to take a fresh look at Christopher Alexander." That's all well and good, and as far as I know the concept of pattern languages could be very useful; I wouldn't know, I've never heard of it till today, and in fact still have no idea what it's about. Which brings me to my point, which is to wonder why the author chose to waste an entire 5 minute and 13 slide presentation (5 of which were dedicated just to bashing design patterns) to making the point that "we need to take a fresh look at Christopher Alexander," instead of, say, spending more time introducing Alexander's ideas and presenting ways they could be useful in our domain. I will conclude by pointing out another pet peeve of mine, which is sensationalist titles only tangentially related to the content. Design pattern, most certainly, ARE. What they are NOT is pattern languages, which is a similar sounding but entirely different concept. </ grumpy geezer mode>

deleted 15y ago
[deleted]
DanielRibeiro 15y ago
There was also a great discussion about this on Stack overflow: http://stackoverflow.com/questions/327955/does-functional-programming-replace-gof-design-patterns http://stackoverflow.com/questions/327955/does-functional-pr... TL;DR: Gof had in mind C++ and Smalltalk. Some languages eliminate the need for many of the patterns in GoF, and they don't eliminate the idioms (patterns for a particular language), as they barely cover it. Another good info on the subject is this presentation: http://www.infoq.com/presentations/Functional-Design-Patterns http://www.infoq.com/presentations/Functional-Design-Pattern...

ericbb 15y ago

Sounds like the Ubiquitous Language idea from Domain Driven Design is a closer analogue. I haven't read Christopher Alexander's book so I'm just going on the article's summary. http://domaindrivendesign.org/node/132 http://domaindrivendesign.org/node/132

aaimnr 15y ago

The critique of GoF presented is superficial. The main difference being GoF's 'how' against Alexander's 'what' doesn't come from GoF's misunderstanding of Alexander's original work. It comes from a different role of architecture of a building versus an architecture of a computer program. It's easier to say about Alexander's pattern that it provides an answer for a 'what' question because the building's architecture is something that people interact with directly with all their senses. Hence a pattern like "159. LIGHT ON TWO SIDES OF EVERY ROOM" ( http://www.patternlanguage.com/apl/aplsample/apl159/apl159.htm http://www.patternlanguage.com/apl/aplsample/apl159/apl159.h... ) seems like an end in itself when compared to eg. a iterator pattern, which obviously always will be described merely as a mean to some more general functionality of the application. The truth is, "LIGHT ON TWO SIDES OF EVERY ROOM" is also a mean - a mean to making a room more bright, pleasant and friendly . If it feels more substantial than an iterator pattern, it's just because we directly interact with an architecture of a building in contrast to the architecture of a software, which is always hidden. There's nothing wrong with GoF, it just follows from the essential quality of a computer software.

keithnoizu 15y ago

What, is this not how we've been using design patterns all along? I always used these patterns to simplify the explanation of how the architecture should or could work. I've never referred to some master cheat sheet of patterns I can copy and paste into my source code to save time, you generally need to custom fit your solutions to the problem at hand.

zwieback 15y ago

When I read the GoF book in '95 it was a revelation, I had learned C++ a few years earlier and here were all the things I had seen in my and other people's code with names and explanations. At the time Rogue Wave hosted an informal lunch meeting in our town where they and some OSU guys discussed patterns, I attended as a visitor and to me it just seemed magical. Over the years some of the high hopes have been dashed but I think some of the core pattern ideas have become useful standard idioms. A year or so after reading the GoF book I saw the Alexander book in a used book store and picked it up to see what it was all about and I was very surprised. I like the book a lot but I really don't think the parallels with the GoF book and the software design patterns are all that strong. The Alexander book does not seem very systematic or analytic, it's more rambling and philosophical. I'm not an architect so I probably don't see the big picture but to me the book seems to lack a coherent vision. If you're interested how Alexander himself saw himself fit into the emerging pattern movement, here's a link to James Coplien's description of Alexander's OOPSLA appearance in '96: https://sites.google.com/a/gertrudandcope.com/info/Publications/Oopsla96/feetofmaster-html https://sites.google.com/a/gertrudandcope.com/info/Publicati... Hard to believe it's been 15 years!