A fresh look at patterns

Via Aaron I found a slide entitled ”’Design Patterns’ Aren’t” by someone called M. J. Dominus. My first reaction was that he’s gotten it all wrong, but his argument for taking a fresh look at Christopher Alexander’s patterns appealed to me and I want to find out more about it. But first I want to address what I feel is a misundersting about design patterns.

Dominus says that the book Design Patterns (often called “Gang of Four” or “GoF”) is equivalent to a library of C++ code, from which snippets can be copied and pasted into your own code. This is not true. A design pattern is a form for documenting a recurring solution to a design problem (I know he quotes this phrase). It’s not tied to any specific programming language and as a matter of fact, most of the patterns in the book doesn’t even lend themselves to being expressed as reusable code. This is particularly true of patterns such as Decorator and Facade. The code snippets in the book are sample implementations. It’s the idea, if anything, that is reused!

I also get the feeling that he tries to bring down design patterns by making it look ridiculous, saying for example that Perl’s foreach statement renders the Iterator pattern useless and that design patterns encourage the use of obsolete languages. The point with Iterator and many other patterns is to keep objects from knowing about the internals of other objects – or, in this case, collections and aggregations. If you have ten types of collections, you would only have one Iterator interface, albeit ten concrete Iterator implementations, each knowing how to traverse that specific collection. I don’t know much about Perl, but I’m sure that foreach doesn’t solve this problem, although he’s right that there is less need for it in a more dynamic language such as Perl.

Design patterns can be specific to a language, though. Common Perl idioms and recurring solutions that exploit features specific to Perl, could be documented as design patterns and thus be helpful to lots of (perhaps less experienced) Perl programmers. And design patterns are very effective for conveying design ideas and will hopefully be more broadly adopted in the future – not as a cookbook, but as a way to improve people’s design skills and to facilitate discussion among programmers.

But, as Dominus says in the postscript, his point is that we need to take a fresh look at Christopher Alexander. On slide nine he explains Alexander’s motivation for patterns as being a format for delegating design decisions to the “users of the design” (that is, the people that will use the building). “Suppose you want to design a college campus[, you must then] delegate the some of the design [decisions] to the students and professors”.

On slide twelve he describes the difference between Alexander’s patterns and GoF patterns. The former “does not tell you how to design anything[, it] helps you decide what should be designed”. The main difference being that with the Alexandrian way, you “get to make up whatever patterns you think will lead to good designs” whereas with GoF the “idea is to discover existing patterns of software development”. I’m not so sure that Alexander meant that patterns are to be always made up. Although that might happen, I think the norm is to look for proven solutions (such as “alcoves” and “ceiling height variety”), which is what GoF says too. It is easier for people to talk about something with which they can relate, such as alcoves. If a new pattern were to be created, my bet is that it would be a combination, or variation, of already existing solutions (“patternized” or not), such as an “alcove with ceiling height variety”; or, an aggregation of several patterns (which would in effect be a higher-level abstraction).

I do agree that these two approaches are different, and I find that difference very interesting. The fact that I have read lots of articles and books on software patterns (but none of Alexander’s) and never have heard about this aspect of patterns, suggests that Dominus is right in his claim that GoF “obstructs this niche”.

What’s interesting about the intent of Alexander’s patterns (to make it easier to involve the “users” in the discussion) is that it reminds me of the System Metaphor in Extreme Programming (XP). The metaphor aims at creating a vocabulary that both the programmers and the customers can use when discussing the system being built. The metaphor is perhaps the most misunderstood part of XP and perhaps it would benefit from being “cross-bred” with the Alexander’s intention with patterns?

Cross-breeding patterns with the metaphor would probably make the metaphor more formal, which I think would be a good thing. I have the feeling that most people approaching XP only vaguely understand what the metaphor is about, and although they are convinced that it is a good idea, they are still clueless as to how you “create” a metaphor.

I think I will have to nominate Alexander’s Timeless Way of Building and A Pattern Language for inclusion in our company library.

The above was posted to my personal weblog on July 12, 2002. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)