When introduced to the concept of patterns, many developers tend to focus on the solutions presented in specific patterns. In doing so, however, they miss much of the broader context and style of thinking associated with patterns. A pattern is not simply about a solution: it is also about the connection between a problem and a solution. A pattern represents a model of reasoning and a way of thinking about a design, from the context of the problem, through the forces that create design tension, to the proposed solution that resolves this tension and then on to a consideration of the consequences (good and bad) of applying the solution.
In addition to the detail that makes a pattern relevant and practical, a well-written pattern description should include a simple statement of the problem and a simple statement of the solution. Sadly, although most pattern descriptions provide some kind of summary, many fail to summarise the actual problem and solution. Readers are immediately drawn into the mechanics, becoming lost in minutiae, special cases and minor variations without necessarily seeing the bigger picture and understanding the essence of the pattern. The omission of such a simple summary of the problem and solution perhaps helps to explain why some patterns are frequently misapplied or require frequent clarification and re-explanation.
But there is something else that is important in describing a pattern, something briefer even than a problem–solution summary. It is always present, but its value is often overlooked.
The Naming of Cats
One of the oft-cited benefits of identifying, describing and naming a pattern is surprisingly simple: the name. Pattern names help to form a design vocabulary. Instead of arm waving and re-describing a design concept each time we want to talk about it, we can simply use the name of the pattern. Patterns don’t just allow us to refine our personal design skills and expand our architectural knowledge, they allow us to communicate.So, what makes a good pattern name? A pattern name should speak for itself and not require too much supporting explanation – it’s supposed to communicate, right? For example, consider the contrasting examples described by xUnit Test Patterns author Gerard Meszaros: 19b65e3b09663b757c2cc408cb187b0a
So what should a pattern be named after? A pattern should be named after some defining characteristic of the solution – ideally as a noun phrase – and not after some aspect of the problem being solved. Problems often open themselves up to more than a single solution, so it would be a little presumptuous to have a name that claims the whole problem space.
Sometimes a pattern name can appear to refer to the nature of the problem, whereas it was intended to refer to an aspect of the solution. For example, in spite of appearances, the STATE pattern is not in fact named after the problem it addresses, which concerns implementing state-dependent behaviour. It is named for a role in the solution structure, an object that represents state-dependent behaviour. However, this is not obvious and many people assume that it is the only OO pattern for addressing state-related problems, which is certainly not true. The pattern’s alternative name, OBJECTS FOR STATES, more clearly describes the solution structure and is far less open to misinterpretation.
Talking patterns
Unless we are talking specifically about the pattern itself, it can be a bit clumsy and overly ceremonial to always refer to a pattern as a formal name, using caps and framing it with a the prefix and pattern suffix each time we mention it. A good pattern name is one that can be stripped of such adornment and used easily as part of a normal conversation (well, as normal as any conversation about software development can be). So, instead of saying something like “We use the DATA TRANSFER OBJECT pattern to pass the request details between threads”, we would say “We pass the request details between threads in a data transfer object”.A good pattern name should be modest and act as a regular part of speech rather than draw unnecessary attention to itself. This means that the unqualified use of the pattern name should not lead to clumsy phrasing or ambiguity. Consider the following statement about a particular refactoring episode: “I used the STRATEGY pattern to eliminate all the messy conditional code”. Although this reads as a strident and confident affirmation of the STRATEGY pattern, at least it is not inaccurate or vague. Dropping the full qualification does not, in this case, result in an improvement: “I used a strategy to eliminate all the messy conditional code” or “I used strategy to eliminate all the messy conditional code”. Using some strategy, or being strategic, rather than taking some ad hoc approach to eliminate messy code? That sounds very wise! But it’s not what was intended.
The strategy moniker can be a little too nebulous. The metaphor alluded to fails to offer a concrete guideline or solution structure. An alternative name for the same pattern, used by Kent Beck in Smalltalk Best Practice Patterns, is PLUGGABLE BEHAVIOUR. This is not only a more precise description of the solution, but it flows more naturally in a sentence: “I used pluggable behaviour to eliminate all the messy conditional code”.
In some cases a pattern name comes naturally from the terms normally used to describe a solution. For example, both the PROXY and the DATABASE ACCESS LAYER patterns take their names from recognised and common descriptions of the designs involved. They sound like ordinary descriptive terms because that is their origin. In other cases the name has to be coined by a pattern author, and this is where names can easily become too clever or too clumsy. (A little secret: every pattern author, no matter how good, has at least one pattern name that qualifies in this category).
Telling stories
Having a vocabulary for describing a design means that we have a complementary technique for describing its structure, one that is more motivating and makes more sense of the design than an alphabetised shopping list of classes. A pattern story brings out the sequence of patterns applied in a given design example. A pattern story offers a conceptual narrative behind a given piece of design. This narrative may be real or illustrative. Often the purpose of a story is to provide a version of events that allows the reader to make sense of the outcome; it is not necessarily intended to be a piece of honest journalism about what actually happened – to quote James Burke: “History rarely happens in the right order or at the right time, but the job of a historian is to make it appear as if it did.” So it is with pattern stories.Consider the following simple story fragment, presented as alternating problem–solution pairs and with each problem is phrased as a question: e615745f336c7983c2ce53b8ac75b89c
Although there is certainly more to tell, such as how the script is parsed and how the syntax tree is built, this fragment still presents a complete design fragment in its own right, enough to illustrate the basic idea of pattern stories. Underpinning a pattern story is a pattern sequence, in this case: <COMMAND, CONTEXT OBJECT, COMPOSITE>. Where a story is filled with concrete detail, a sequence captures the gist; generalised roles and themes rather than characters and specific situations.
Compound interest
A particular pattern sequence may be small enough and common enough that we may often identify it as a single pattern, one key design decision rather than many. For example, a close look at the MODEL–VIEW–CONTROLLER pattern reveals a number of familiar patterns, including OBSERVER, PLUGGABLE BEHAVIOUR and COMPOSITE. In a pattern compound (also known as a compound pattern or, slightly confusingly, a composite pattern) we can see the parts, but we can name the combination as one idea. It is certainly more convenient to talk about MVC than OBSERVER + PLUGGABLE BEHAVIOUR + COMPOSITE + … Naming the whole, in this case, offers brevity and directness, omitting unnecessary detail. Another example is that the scripting pattern story we just walked through can also be understood as an application of the INTERPRETER pattern.So should we consider a pattern compound to be one pattern or many? Should we view it as INTERPRETER or as <COMMAND, CONTEXT OBJECT, COMPOSITE>? The answer is “yes”. Or, more accurately, “it depends”. Or, from Douglas Hoftstadter’s Gödel, Escher, Bach, by analogy: aa81890fd5b4e019059591381dd89c8f
When we generalise the idea of patterns as vocabulary, such as the notion that we can relate designs as a narrative, we start to consider if there is a way of organising a collection of patterns that allows us to talk about how to design particular kinds of systems or subsystems or how to add particular features to our code. This is where pattern languages come into play… but that’s another story.
Comments