| Christopher Alexander, an architect, professor, and social commentator, inspired the software patterns movement with two literary masterpieces, A Timeless Way of Building [Alexander, TWB] and A Pattern Language [Alexander, PL]. Beginning in the late 1980s, software practitioners with years of experience began studying Alexander's works and sharing their knowledge in the form of patterns and intricate networks of patterns, known as pattern languages. This led to the publication of valuable papers and books about patterns and pattern languages in such areas as object-oriented design, analysis and domain design, process and organizational design, and user interface design. Pattern authors have often debated how to define a pattern, and many of the disagreements stem from how close to or far from Alexander's view the debaters are. As I'm partial to Alexander's view, I'll quote him directly: Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves. As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant. The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing. [Alexander, TWB, 247] Our industry's view of patterns has mostly been influenced by catalogs of individual patterns, such as those found in Design Patterns [DP] and Martin Fowler's Patterns of Enterprise Application Architectures [Fowler, PEAA]. Such catalogs don't actually contain stand-alone patterns because authors typically discuss which alternative patterns to consider if a pattern doesn't provide a good fit. In recent years, we've also seen the emergence of literature that resembles Alexander's pattern languages. Such works include Extreme Programming Explained [Beck, XP], Domain-Driven Design [Evans], and Checks: A Pattern Language of Information Integrity [Cunningham]. |
