A pattern language is an organized and coherent set of patterns, each of which describes a problem and the core of a solution that can be used in many ways within a specific field of expertise. The term was coined by architect Christopher Alexander and popularized by his 1977 book A Pattern Language. A pattern language can also be an attempt to express the deeper wisdom of what brings aliveness within a particular field of human endeavor, through a set of interconnected patterns. Aliveness is one placeholder term for "the quality that has no name": a sense of wholeness, spirit, or grace, that while of varying form, is precise and empirically verifiable. Alexander claims that ordinary people can use this design approach to successfully solve very large, complex design problems. == What is a pattern? == When a designer designs something – whether a house, computer program, or lamp – they must make many decisions about how to solve problems. A single problem is documented with its typical place (the syntax), and use (the grammar) with the most common and recognized good solution seen in the wild, like the examples seen in dictionaries. Each such entry is a single design pattern. Each pattern has a name, a descriptive entry, and some cross-references, much like a dictionary entry. A documented pattern should explain why that solution is good in the pattern's contexts. Elemental or universal patterns such as "door" or "partnership" are versatile ideals of design, either as found in experience or for use as components in practice, explicitly described as holistic resolutions of the forces in recurrent contexts and circumstances, whether in architecture, medicine, software development or governance, etc. Patterns might be invented or found and studied, such as the naturally occurring patterns of design that characterize human environments. Like all languages, a pattern language has vocabulary, syntax, and grammar – but a pattern language applies to some complex activity other than communication. In pattern languages for design, the parts break down in this way: The language description – the vocabulary – is a collection of named, described solutions to problems in a field of interest. These are called design patterns. So, for example, the language for architecture describes items like: settlements, buildings, rooms, windows, latches, etc. Each solution includes syntax, a description that shows where the solution fits in a larger, more comprehensive or more abstract design. This automatically links the solution into a web of other needed solutions. For example, rooms have ways to get light, and ways to get people in and out. The solution includes grammar that describes how the solution solves a problem or produces a benefit. So, if the benefit is unneeded, the solution is not used. Perhaps that part of the design can be left empty to save money or other resources; if people do not need to wait to enter a room, a simple doorway can replace a waiting room. In the language description, grammar and syntax cross index (often with a literal alphabetic index of pattern names) to other named solutions, so the designer can quickly think from one solution to related, needed solutions, and document them in a logical way. In Christopher Alexander's book A Pattern Language, the patterns are in decreasing order by size, with a separate alphabetic index. The web of relationships in the index of the language provides many paths through the design process. This simplifies the design work because designers can start the process from any part of the problem they understand and work toward the unknown parts. At the same time, if the pattern language has worked well for many projects, there is reason to believe that even a designer who does not completely understand the design problem at first will complete the design process, and the result will be usable. For example, skiers coming inside must shed snow and store equipment. The messy snow and boot cleaners should stay outside. The equipment needs care, so the racks should be inside. == Many patterns form a language == Just as words must have grammatical and semantic relationships to each other in order to make a spoken language useful, design patterns must be related to each other in position and utility order to form a pattern language. Christopher Alexander's work describes a process of decomposition, in which the designer has a problem (perhaps a commercial assignment), selects a solution, then discovers new, smaller problems resulting from the larger solution. Occasionally, the smaller problems have no solution, and a different larger solution must be selected. Eventually all of the remaining design problems are small enough or routine enough to be solved by improvisation by the builders, and the "design" is done. The actual organizational structure (hierarchical, iterative, etc.) is left to the discretion of the designer, depending on the problem. This explicitly lets a designer explore a design, starting from some small part. When this happens, it's common for a designer to realize that the problem is actually part of a larger solution. At this point, the design almost always becomes a better design. In the language, therefore, each pattern has to indicate its relationships to other patterns and to the language as a whole. This gives the designer using the language a great deal of guidance about the related problems that must be solved. The most difficult part of having an outside expert apply a pattern language is in fact to get a reliable, complete list of the problems to be solved. Of course, the people most familiar with the problems are the people that need a design. So, Alexander famously advocated on-site improvisation by concerned, empowered users, as a powerful way to form very workable large-scale initial solutions, maximizing the utility of a design, and minimizing the design rework. The desire to empower users of architecture was, in fact, what led Alexander to undertake a pattern language project for architecture in the first place. == Design problems in a context == An important aspect of design patterns is to identify and document the key ideas that make a good system different from a poor system (that may be a house, a computer program or an object of daily use), and to assist in the design of future systems. The idea expressed in a pattern should be general enough to be applied in very different systems within its context, but still specific enough to give constructive guidance. The range of situations in which the problems and solutions addressed in a pattern apply is called its context. An important part in each pattern is to describe this context. Examples can further illustrate how the pattern applies to very different situation. For instance, Alexander's pattern "A PLACE TO WAIT" addresses bus stops in the same way as waiting rooms in a surgery, while still proposing helpful and constructive solutions. The "Gang-of-Four" book Design Patterns by Gamma et al. proposes solutions that are independent of the programming language, and the program's application domain. Still, the problems and solutions described in a pattern can vary in their level of abstraction and generality on the one side, and specificity on the other side. In the end this depends on the author's preferences. However, even a very abstract pattern will usually contain examples that are, by nature, absolutely concrete and specific. Patterns can also vary in how far they are proven in the real world. Alexander gives each pattern a rating by zero, one or two stars, indicating how well they are proven in real-world examples. It is generally claimed that all patterns need at least some existing real-world examples. It is, however, conceivable to document yet unimplemented ideas in a pattern-like format. The patterns in Alexander's book also vary in their level of scale – some describing how to build a town or neighbourhood, others dealing with individual buildings and the interior of rooms. Alexander sees the low-scale artifacts as constructive elements of the large-scale world, so they can be connected to a hierarchic network. === Balancing of forces === A pattern must characterize the problems that it is meant to solve, the context or situation where these problems arise, and the conditions under which the proposed solutions can be recommended. Often these problems arise from a conflict of different interests or "forces". A pattern emerges as a dialogue that will then help to balance the forces and finally make a decision. For instance, there could be a pattern suggesting a wireless telephone. The forces would be the need to communicate, and the need to get other things done at the same time (cooking, inspecting the bookshelf). A very specific pattern would be just "WIRELESS TELEPHONE". More general patterns would be "WIRELESS DEVICE" or "SECONDARY ACTIVITY", suggesting that a secondary activity (such as talking on t
Read more →
