The Alexandrian and the Structured Pattern Form

27-11-2011 | Category: Patterns | Tags: Pattern Forms

Patterns document well-proven solutions to recurring problems. They generalize a set of related problems, carefully document the forces being applied in the context of this problem, and give a possible solution. In essence, patterns are building blocks of knowledge, small gems that you name, apply, and communicate to others. In this post, I further explain patterns and show the two most common forms how patterns are presented.

The essential role of patterns is that they help you to document recurring problems and their solution, in a form that helps to spread this knowledge to others. Over the years of using patterns, two forms were developed: The alexandrian form and the structured form.

Alexandrian form

The alexandrian form is named after Christopher Alexander, the original inventor of patterns with his book “A Pattern Language – Town, Buildings, Construction” [¹]. Alexander explains patterns in a prose form, a short essay. Alexander introduces a pattern with a small description of the context, that describes the general situation in which you may find yourself in. Then, Alexander lists the problems that apply to your situation, the challenges that you are coping with. Forces are shaping this problem, they are often conflicting with each other and force you to make a balanced decisions. Finally, the keyword therefore introduces the solution to your challenges. The solution is a general description, you must adapt it to be useable to your concrete situation.

Structured form

The structured form follows the same content sequence as in the alexandrian form, yet it provides a clear, visually separated structure for each aspect of the pattern. The seminal work on patterns for programming by Gamma et al., Design Patterns – Elements of Reusable Object-Oriented Software [²], uses clear headers and paragraphs. This form helps you to easily navigate to the most important sections. For example, if you prefer to learn from a concrete example, then you can consider just the example sections.

Which form to use?

I learned about these pattern forms during my first Conference on Pattern Languages of Programs. A presentation and discussion led by Joshua Kerievsky explained these two forms and when you should use which form. The baseline argument for the structured form is that it is easier to navigate. It helps you to quickly find what you are mostly interested in, and from this point on, build your knowledge by reading the other sections. A bit controversial is that the structured form also allows you to provide much more details that you need to communicate, but then you also need more time to understand it. In favor of the alexandrian form is its quickly digestible form – well written, it allows you to learn a pattern very fast. Also, the narrative nature makes it easy to learn about the relationships of the patterns that you are presenting.

So, in essence the question “which form to use” boils down to the question how much details you need to provide. For complex patterns that require some amount of background information that you give, you should use the structured form. If you want to address a general audience and establish a pattern language, then you should use the alexandrian form.

What I use

DSL patterns are quite complex. They require that you understand the particularities of the host language, the syntactic or semantic change that you do, its implementation and implication, and how best to combine them. It is best to use learn this information step-by-step, with a structure that allows to quickly navigate to the most interesting parts.

Therefore, I will use the structured form to explain my patterns.

References

¹ Alexander, C.; Ishikawa, S. & Silverstein, M. A Pattern Language – Town, Buildings, Construction. Oxford University Press, 1977

² Gamma, E.; Helm, R.; Johnson, R. & Vlissides, J. Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley, 1997

Comments & Social Media

Tweet

blog comments powered by Disqus