Patterns and Pattern Languages

Appendix. Patterns and Pattern Languages

ONE SIDE BENEFIT OF THIS PROJECT HAS BEEN TO SEE HOW "PATTERNS" ARE BEING ACCEPTED BY THE development community. Since the Ajax Patterns began to be published, the focus has always been on the "Ajax" and not the "Patterns." For patterns, this is a good thing, and a welcome change from the late '90s, when you not only had to explain the concept but also justify its existence. "Ajax" itself is a patternone whose popularity is further evidence for the power of "just a name." For all these reasons, this discussion of patterns and their relationship to Ajax Patterns is kept brief.

Patterns came about in the late 1970s, after Christopher Alexander and colleagues spent years studying the towns and buildings of many diverse cultures. The findings were summarized as 253 distinct patterns, derived from a global pattern describing the division of nations to town-planning patterns such as "Market of Many Shops," all the way down to building patterns like "Soft Tile and Brick." Each pattern is a "thing" you often see in good designs, combined with instructions on making the thing.

Patterns have mostly been confined to academia in their original field, but they have really taken off in software design. Their rise over the past decade has been a great boon to the industry, allowing us to learn about design from real examples and not just vague comments about cohesion, coupling, and encapsulation. The pool of real examples to draw upon has itself risen exponentially, thanks to the Web and the open source movement.

The best-known patterns are software design patterns like Gamma et al.'s Design Patterns (1995). But that's not the only domain of software patterns, which have been applied to development processes, deployment practices, andmost important hereusability. Just as the original architecture patterns were fundamentally about improving the experience of inhabitants, usability patterns focus on the people who userather than developsoftware systems. They have been especially popular for web design (e.g., The Design of Sites (Duyne et al., 2003), A Pattern Language for Web Usability (Graham, 2003), Martijn van Welie's "Web Design Patterns" at http://www.welie.com/patterns/). The Web is ideal for design patterns because examples are readily available for authors to mine and readers to try out.

The Ajax Patterns continue the tradition of web usability patterns, though they focus as much on technical design as on usability. As Alexander et al.'s work shows, it's perfectly possible (desirable, even) for a single language to range across several levels of abstraction. The first three sections of Alexander's work progress from low-level operations to high-level functionality and usability concepts. The fourth section is somewhat separate, as it addresses practices relevant to all those earlier sections, and in that sense is similar to some of the process-oriented pattern languages.

The question has arisen: are these patterns? According to most definitions, these are indeed; each Ajax Pattern shows how real projects have solved a recurring problem. In some cases, there's some speculation involved, but as long as any lack of evidence is declared and the idea is useful, I believe it's worth documenting in the pattern form. Another question here: is this a pattern language, or just a collection of patterns? I'm inclined to say the former, because the patterns are closely linked, filtered according to a consistent set of principles, and generative in that they build on each other. In any event, the most important question here is not about definitions, but about utility: how useful are the Ajax Patterns? I certainly hope the patterns are useful and practical, but I'll let you be the judge of that.