Design Patterns Explained

194 Part IV • Putting It All Together: Thinking in Patterns
This was compounded by the fact that many key designers in the
software community were espousing the development of "pattern
languages"— looking for formal ways to apply Alexander to
software. I interpreted this to mean that we were close to being
able to apply Alexander's approach directly in software design (I
no longer believe this to be true). Since Alexander said patterns
in architecture had predetermined orders of context, I assumed
patterns in software also had this predetermined order. That is,
one type of pattern would always create the context for another
type. I began to evangelize about Alexander's approach— as I
understood it— while teaching others. A few months and a few
projects later, I began to see the problems. There were cases
where a preset order of contexts did not work.
Having been trained as a mathematician, I only needed one
counterexample to disprove my theory. This started me questioning
everything about my approach— something I usually did, but
had forgotten in my excitement.
Since that early stage, I now look at the principles upon which
Alexander's work is based. While they manifest themselves differently
in architecture and in software development, these principles
do apply to software design. I see it in improved designs. I
see it in more rapid and robust analysis. I experience it every
time I have to maintain my software.
Summary
In this chapter Design is normally thought of as a process of synthesis, a process of
putting things together. In software, a common approach is to look
immediately for objects and classes and components and then think
about how they should fit together.
In The Timeless Way of Building, Christopher Alexander described a
better approach, one that is based on patterns: