Pattern Language
Positioning
The Failure Patterns addressed in this site are not for classifying individual problems or causes.
In treating recurring situations and the dynamics that tend to arise under those situations as units, they strongly connect with the concepts of Pattern Language.
The Pattern Language referenced here refers not to a catalog of design solutions, but to Pattern as a unit of thought for capturing problems.
Scope
This Appendix does not address the historical background or systematic organization of Pattern Language.
The discussions of Alexander and Coplien are only referenced as the philosophical background when adopting the unit called Failure Pattern.
The application of specific design methodologies or organizational patterns is outside the scope of this site.
Mapping
The following organizes the correspondence between elements in this site and concepts of Pattern Language.
| Element in Main Text | Position in Pattern Language |
|---|---|
| Failure Pattern | Named unit for handling recurring situations |
| Context / Forces / Consequences | Structure for describing separately the assumptions, dynamics, and outcomes under which a Pattern holds |
| Countermeasures | Not solutions, but directions for shifting dynamics |
| Resulting Context | New situation that may be established after Pattern application |
Rationale
What is important in Pattern Language is not presenting "correct design."
It lies in sharing as a common language the reason why specific situations recur repeatedly and the range of decisions that can be taken under those situations.
Failure Patterns are likewise designed not to determine the cause of problems, but as a device for referring by name to situations occurring in the field.
References
- Christopher Alexander, A Pattern Language: Towns, Buildings, Construction, 1977.
- Christopher Alexander, The Timeless Way of Building, 1979.
- James O. Coplien, Software Design Patterns: Common Questions and Answers, 1994
- James O. Coplien, Neil B. Harrison, Organizational Patterns of Agile Software Development, 2004.