"Design Patterns Aren't" is a paper/talk by M.J.Dominus of Plover Systems Co. He argues that "Patterns" as explained by the GOF and used in the computing communities are not the same as "Patterns" as described by Alexander. He further argues that while GOF-Patterns might be useful, they are not as useful or interesting as Alex-Patterns.
Quoting from the postscript:
You can read the slides from the talk here:
I found that they articulated something that's been worrying me for years, but have never been able adequately to explain.
I found that it is a rant that C++ doesn't do things as well as Perl, and that is somehow a reason that the GoF patterns are not Alexandrian patterns. I also think it is a misreading of Alexander's idea in the first place, given the stuff I've read about his Design Patterns -- PeteHardie
I think there is something to it. If I read it correctly examples are alexanderish patterns would be
The only GoF-pattern that really is a pattern in this sense then is
I can't find the link anymore, but there was a page detailing some of Alexander's patterns, and they were along the lines of "use low ceilings for intimacy", and "provide private spaces", which, to me, seem quite similar in detail to the GoF patterns. Sure, many developers might just cut&paste the example code, but that does not mean the patterns have use for the developers who understand the deeper meaning. --PeteHardie
Oh they are related sure. But the GoF thing is more like:
Whereas Alexander seems to read more like
-- .gz
There are similarly precise instructions in some of the comments about the design of office space - notably "have windows that open". I think that the example code that goes with the GoF pattern description may be too precise, but that's not the pattern, it's a reference implementation --ph
I think slides 11, 12a and 12b hold the real message.
I think slide 11 merely says "Have a standard vocabulary of terms to discuss constructions". Not a bad idea, but no more profound than the vocabulary textbooks we had in 2nd grade reading/writing classes. The profoundness lies in having a way to discuss why and when to use different patterns, and the effects they will have on the overall construct, and how they combine. That's what makes it a pattern language rather than just a list of buzzwords. There's no use discussing terms that you don't understand, and the source examples for the GoF patterns are the illustration that's worth a thousand words to programmers, so that they'll understand, recognize, and know what they're talking about when discussing the patterns. They're the 'what' is being talked about. Although they could be used as a 'how', that's not what they're for, as I read it.
Please link this into WardsWiki in the appropriate places.
See also: SoftwarePatternsArentAlexanderPatterns