Ruminations on Studying Design Patterns

As regular readers will know, I have been spending time over the last year studying and trying to digest the contents of Design Patterns (Gamma, Helm, Johnson & Vlissides). I have decided to call it a day. The reasons for this decision are probably more instructive than my attempts at adding to your understanding by my articles here.

One of the principles for Design Patterns (or Patterns in general) is that they are the distillation of good practice based on at least three distinct uses. I have on several occasions taken others to task because the write or speak about 'inventing' a Pattern. Patterns can, by their very nature, only be discovered or recognised. I suspect that most of the single thread design patterns have already been discovered and documented which is what makes them a useful tool in furthering design of new software.

Let me digress for a moment and ask you how you would describe symphonic form to someone whose musical experience was restricted to playing solo music on a Recorder? Even if they were a superb technician with the instrument and had a profound sense of musical interpretation they would completely lack the relevant experience for any meaningful understanding of orchestral musical forms. The first requirement would be to broaden their experience by exposing them, at least as listeners, to a much wider range of musical experience. Only at that stage could you hold a dialogue with them on the subject of different orchestral forms. Even then their grasp would probably be pretty mediocre, they would need to extend their understanding by either dissecting several substantial pieces or by writing (however badly) some orchestral music themselves.

Note that I am concerned with understanding and not just a superficial ability to imitate. Much bad poetry, poor writing and superficial painting comes about from imitation without understanding. The observer can often identify the lack of quality without being able to identify what is wrong. For example I can remember having a professionally produced play (in a major London theatre) completely wrecked for me by the bad lighting. Most of the audience knew something was not right, having worked on the technical side of theatre I could point unambiguously at an incorrectly placed lighting bar which was far too low. The lighting engineer should have been sacked because he was clearly incompetent and destroyed the work of others by his failures.

Now let me return to my studies of Design Patterns. Fundamentally I am ill-equipped for such a study because I have insufficient experience of large scale software design. I have written a couple of reasonably large (25000+ line) programmes but that does not give me either the breadth or depth of experience to relate largely verbally described patterns with solutions to problems that I have experienced. Design Patterns is clearly a good book for those with relevant experience as it allows them to crystallise their experience and provides them with a common language for discussion with others. However, despite claims made to the contrary, it is not a substitute for experience.

Lower level patterns (such as some of those described by Frank Buschmann in Pattern-Oriented Software Architecture) and idioms are fine for me because I have the relevant experience to understand them and relate them to my own experience. I am also pretty certain that many of the intermediate patterns are relevant but I need more help in understanding them. I suspect that I am not alone in this. I also suspect that many others are hiding their lack of understanding because they think they ought to know. They use the terminology, often incorrectly, but in a way that is analogous to name-dropping.

Let me take a little time suggesting a way forward.

I am quite disturbed by the idea that students should be taught patterns as some kind of academic study. Before they study patterns they should be exposed to good software design and have a wealth of material to study. When studying any particular pattern they should be provided with at least three examples of its correct use as well as one or more examples of incorrect or inappropriate usage. (It is only by the contrast between the two that most will be able to abstract what the pattern is, what it does and why it works)

What I would like to see is articles (in Overload) that tackle a single pattern with several examples of its use. The supporting material could be provided on the ACCU Web site. I would also be interested to see the production of a series of short books each dedicated to one or two patterns. Instead of authors looking for new patterns, let us see knowledgeable authors writing comprehensively about those that have already been documented. I know that some will look at this idea with disdain because they will claim that what is already written is enough. It probably is for people at their level of expertise but I am pretty certain that it is not for the majority. Unfortunately working programmers will claim they do not have the time to study. This is why I suggest a series of short monographs. A team leader should be able to ask members of his team to read up on a specific pattern. Students should be able to go and study a pattern in depth. This means that the examples must be properly explained and an attempt made to document why the pattern solved a real design problem. It is no good saying patterns are obvious. That is among the least helpful of responses to someone asking for help.

A story told about an Oxford lecturer (one of the Whitehead brothers, I think) illustrates this point. Apparently one day he wrote a theorem or lemma up on his blackboard and declared that the proof was obvious. He then looked again and walked out of the room. Forty minutes later he returned to what was left of his audience and said 'It was.'

Now which one of you is willing to pick a pattern and present three suitable uses of it in sufficient detail so that even I can understand what it is and why it solves the problem? If no one does I will begin to suspect it is because none of you understand any of the Design Patterns well enough to explain them with examples.