Patterns organize implicit knowledge about how people successfully solve recurring problems. Patterns describe solutions that have been successfully applied on numerous occasions; they are not theoretical abstractions created in ivory towers.
Christopher Alexander defines a pattern as follows: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” (Alexander, 1997, A Pattern Language)
There are a number of pattern formats available — Alexandrian, GoF, Portland, and Coplien to name a few. While these may differ in style and format, they all attempt to convey the same basic information. Irrespective of the format used, the pattern will at a minimum describe the problem, specify the context in which to apply the pattern, enumerate the forces in-play, and describe the solution in that context. The last part is important — patterns will only solve the problem in an appropriate context; they cannot be applied arbitrarily in all situations.
I am going to use the Alexandrian format throughout this book to describe the best practices. The Alexandrian format contains the following elements:
- Name — single word or short phrase that refers to the pattern. This allows for rapid association and retrieval.
- Aliases
- Context — preconditions which must exist in order for that problem to occur, this is often a situation. When forces conflict, the resolutions of those conflicts is often implied by the context.
- Problem — definition of a problem, including its intent or a desired outcome, and symptoms that would indicate that this problem exists.
- Forces — description of forces or constraints and how they interact, some of the forces may be contradictory, such as being thorough often conflicts with time or money constraints.
- Solution — instructions, possibly including variants, may encompass pictures, pictures, diagrams, prose, or other media
- Resulting Context — result after the pattern has been applied, including post-conditions and side effects. It might also include new problems that might result from solving the original problem.
- Rationale — the thought processes that would go into selecting this pattern, The rationale includes an explanation of why this pattern works, how forces and constraints are resolved to construct a desired outcome.
- Examples — sample applications and solutions, analogies, visual examples, and known uses can be especially helpful, help user understand the context
- Related Patterns — differences and relationships with other patterns, possibly predecessor, antecedents, or alternatives that solve similar problems.
The patterns described in this series of blogs have been observed over the years while working at various client sites. In keeping with the spirit of the pattern-writers value system (http://wiki.c2.com/?PatternValueSystem), I will use existing pattern names where possible — most of these patterns were originally proposed by people like: Jim Coplien, Neil Harrison, Ward Cunningham, Alistair Cockburn, and Don Olson.