Table of contents
A design pattern is a formal way of documenting a solution to a recurring problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. Patterns do not exist in isolation, and they are typically organized into collections of interlinked patterns for a given field. Such collections are referred to as pattern languages.
Pattern languages are a very flexible way of describing the solution space for complex domains. Instead of having to subscribe to all-encompassing, one-size fits all solutions, practitioners can cherry pick the patterns that best represent their particular context, then adapt and re-combine them in original ways to fit a given situation. Another advantage of pattern languages is that they provide practitioners with a common vocabulary for sharing and talking about solutions to problems in their domain.
Although the format and structure of a pattern is open-ended and can be tailored to the needs of particular domains, there are a number of characteristics which are shared by all good patterns. These are described below.
Concise, communicative name
Each pattern has a short name (2-5 words) which captures its essence. Good names are important, because they provide the basic vocabulary that practitioners can use to discuss the solution space for problems in their domain. Coming up with a good name is often the most challenging part of pattern writing, and the inability to do so is often a symptom that the author hasn't yet grasped the actual core of the solution he is describing.
Each pattern must describe the context in which it applies. For example, is this pattern applicable to collaborative translation at large, or is only relevant in volunteer-based translation crowdsourcing situations? Without proper context, the reader cannot easily determine the applicability of the pattern to his current situation.
The pattern must describe the exact nature of the problem that it solves. A common approach is to describe the problem in terms of tensions between opposing forces. Something along the lines of: "On the one hand, one would want X, but on the other hand, one would also want Y, and the two are partly incompatible for reasons A, B and C".
The pattern must describe the solution to the problem. Again, this is often framed in terms of a way to balance the opposing forces mentioned in the problem description, so as to reach a sustainable equilibrium. The solution should be general enough to be applied in very different situations within its context, but still specific enough to give constructive guidance to the practitioner.
Links to related patterns
Patterns generally do not exist in isolation, and relate to other patterns in a given language. These links should be acknowledged explicitly in the pattern, both by referring to them inside the pattern description, and by providing a Related patterns section at the end of the pattern.
Good patterns provide references to real-life examples where it was shown to work. Such examples are important because they provide a sense of how well-tried the pattern actually is.