Pattern Language - Many Patterns Form A Language

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. 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.