Relationships Within a Pattern

I must admit, in my courses, I have some fun with a certain quote from Alexander. After I have been talking about how great patterns are for two-thirds of a day, I pick up Alexander's Timeless Way of Building, turn to the end, and say

This book is 549 pages long. On page 545, which, I think you will agree, is pretty close to the end, Alexander says, “At this final stage, the patterns are no longer important:…”^[1]

^[1] Alexander, C., Ishikawa, S., Silverstein, M., The Timeless Way of Building, New York: Oxford University Press, 1979, p. 545.

I pause to say, “I wish he'd have told me this at the beginning and I could have saved myself some time!” Then I continue to quote from him: “The patterns have taught you to be receptive to what is real.”^[2]

^[2] ibid, p, 545.

I finish with, “If you read Alexander's book, you will know what is real—the relationships and forces described by the patterns.”

The patterns give us a way to talk about these. However, it is not the patterns themselves that are important. This is true for software patterns as well.

A pattern describes the forces, motivations, and relationships about a particular problem in a particular context and provides us with an approach to addressing these issues. The Bridge pattern, for example, is about the relationship between the derived classes of an abstraction and their possible implementations. A Strategy pattern is about the relationships between

• A class that uses one of a set of algorithms (the Context)

• The members of this set of algorithms (the strategies)

• The Client, which uses the context and specifies which of the algorithms to use