Design pattern

Differences from pattern languages in architecture

Although borrowed from Christopher Alexander’s pattern language, the GoF patterns book and similar pattern languages feel as though they have adopted only the superficial form.

CA defined pattern languages in context-problem-solution form to revive and share an architectural language capable of producing QWAN. But software patterns rarely mention QWAN or anything corresponding to it. They seem to focus more on software developers and software’s internal design than on end users and the software’s behavior or appearance.

To work our way toward a shared and living language once again, we must first learn how to discover patterns which are deep, and capable of generating life. If we hope to bring our towns and buildings back to life, we must begin to re-create our languages, in such a way that all of us can use them…. In order to make patterns explicit, so that they can be shared in this new way, we must first of all review the very complex structure of a pattern.

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; both a description of a thing which is alive, and a description of the process which will generate that thing.¹

Footnotes

Chapter 14 “Patterns which can be shared”, The timeless way of building