Building by Adding Distinctions
Now that you have a handle on some of the design patterns, it is time to see how they can work together. For Alexander, it is not enough to simply describe individual patterns. He uses them to develop a new paradigm for design.
His book, The Timeless Way of Building, is both about patterns and how they work together. This is a beautiful book. It is one of my favorite books both on a personal level and on a professional level. It has helped me appreciate things in my life, to understand the environment in which I live, and also to achieve better software design.
How can this be? How can a book about designing buildings and towns have such a profound influence on designing software? I believe it is because it describes a paradigm that Alexander says a designer should work from. Any designer. It is this paradigm of design that I find most interesting.
I wish that I could say I had immediately adopted Alexander's insights the first time I read his book; however, that was not the case. My initial reaction to this book was, “This is very interesting. It makes sense.” And then I went back to the traditional design methods that I had been using for so long.
But sometimes the old sayings turn out to be true. As in, “Luck is when opportunity meets with preparedness.” Or, “Chance favors the prepared mind.” I got “lucky” and that has made all the difference.
Within a few weeks of reading The Timeless Way of Building, I was faced with an opportunity. I was on a design project and my standard approaches weren't working. I had designs, but they weren't good enough. All of my tried and true design methods were failing me. I was very frustrated. Fortunately, I was wise enough to try a new way—Alexander's way—and was delighted with the results.
In the next chapter, I will describe what I did. But first, let's look at what Alexander offers us.
Design is often thought of as a process of synthesis, a process of putting together things, a process of combination. According to this view, a whole is created by putting together parts. The parts come first: and the form of the whole comes second.[1]
[1] Alexander, C., Ishikawa, S., Silverstein, M., The Timeless Way of Building, New York: Oxford University Press, 1979, p. 368.
It is natural to design from parts to the whole, starting with the concrete things that I know.
When I first read this, I thought, “Yes. That is pretty much how I look at things. I figure out what I need and then put it together.” That is, I identify my classes and then see how they work together. After assembling the pieces, I may step back to see that they fit in the big picture. But even when I switch my focus from local to global, I am still thinking about the pieces throughout the process.
As an object-oriented developer, these pieces are objects and classes. I identified them. I defined behavior and interfaces. But I started with pieces and typically stayed focused on them.
Think about the original CAD/CAM solution in Chapter 4, “A Standard Object-Oriented Solution.” I started out thinking about the different classes I needed: slots, holes, cutouts, and so on. Knowing that I needed to relate these to a V1 system and a V2 system, I thought I needed a set of these classes that worked with V1 and another set of these classes that worked with V2. Finally, after coming up with these classes, I saw how they tied together.
But it is impossible to form anything which has the character of nature by adding preformed parts.[2]
[2] ibid, p. 368.
Alexander's thesis is that building from the pieces is not a good way to design.
Even though Alexander is talking about architecture, many software design practitioners whom I respect said that his insights were valid for us as well. I had to open my mind to this new way of thinking. And when I did so, I heard Alexander say that “good software design cannot be achieved simply by adding together preformed parts” (i.e., parts defined before seeing how they would fit together).
When parts are modular and made before the whole, by definition then, they are identical, and it is impossible for every part to be unique, according to its position in the whole. Even more important, it simply is not possible for any combination of modular parts to contain the number of patterns which must be present simultaneously in a place which is alive.[3]
[3] ibid, pp. 368–369.
Alexander's talk about modularity was confusing to me at first. Then I realized that if we start out with modules before we have the big picture, the modules would be the same, since there would be no reason to for them to be different.
This seems to be the goal of reuse. Don't we want to use exactly the same modules again and again? Yes. But we also want maximum flexibility and robustness. Simply creating modules does not guarantee this.
Once I started to learn how to use design patterns—as Alexander teaches—I learned how to create reusable—and flexible—classes to a greater extent than I had been able to do before. I became a better designer.
It is only possible to make a place which is alive by a process in which each part is modified by its position in the whole.[4]
[4] ibid, p. 369.
When you read alive, think robust and flexible systems.
Earlier, Alexander said that parts need to be unique so that they can take advantage of their particular situation. Now, he takes this deeper. It is in coping with and fitting into the surroundings that gives a place its character. Think of examples in architecture:
A Swiss village— Your mind's eye brings up a village of closely nestled cottages, each looking quite similar to the one next to it, but each one different in its own way. The differences are not arbitrary, but reflect the financial means of the builder and owner as well as the need of the building to blend in with its immediate surroundings. The effect is a very nice, comfortable image.
An American suburb— All of the houses are pretty much cookie-cutter designs. Attention is rarely paid to the natural surroundings of the house. Covenants and standards attempt to enforce this homogeneity. The effect is a depersonalization of the houses and is not at all pleasing.
Applying this to software design might seem a bit too “conceptual” at this point. For now, it is enough to understand that the goal is to design pieces—classes, objects—within the context in which they must live in order to create robust and flexible systems.
In short, each part is given its specific form by its existence in the context of the larger whole.
This is a differentiating process. It views design as a sequence of acts of complexification; structure is injected into the whole by operating on the whole and crinkling it, not by adding little parts to one another. In the process of differentiation, the whole gives birth to its parts: The form of the whole, and its parts, come into being simultaneously. The image of the differentiating process is the growth of an embryo.[5]
[5] ibid, p. 370.
“Complexification.” What in the world does that mean? Isn't the goal to make things simpler, not more complex?
What Alexander is describing is a way to think about design that starts by looking at the problem in its simplest terms and then adds additional features (distinctions), making the design more complex as we go because we are adding more information.
This is a very natural process. We do it all the time. For example, suppose you need to arrange a room for a lecture with an audience of 40 people. As you describe your requirements to someone, you might say something like, “I'll need a room 30 feet by 30 feet” (starting simple). Then, “I'd like the chairs arranged theater style: 4 rows of 8” (adding information, you have made the description of the room more complex). And then, “I need a lectern at the front of the room” (even more complex).
The unfolding of a design in the mind of its creator, under the influence of language, is just the same.
Each pattern is an operator that differentiates space: that is, it creates distinctions where no distinction was before. And in the language the operations are arranged in sequence: so that, as they are done, one after another, gradually a complete thing is born, general in the sense that it shared its patterns with other comparable things; specific in the sense that it is unique, according to its circumstances.
The language is a sequence of these operators, in which each one further differentiates the image, which is the product of the previous differentiations.[6]
[6] ibid, pp. 372–373.
Alexander asserts that design should start with a simple statement of the problem, then make it more detailed (complex) by injecting information into the statement. This information takes the form of a pattern. To Alexander, a pattern defines relationships between the entities in his problem domain.
For example, consider the Courtyard pattern discussed in Chapter 5, “An Introduction to Design Patterns.” The pattern must describe the entities that are involved in a courtyard and how they relate. Entities such as
The open spaces of the courtyard
The crossing paths
The views outward
And even the people who are going to use the courtyard
Thinking in terms of how these entities need to relate to each other gives us a considerable amount of information with which to design the courtyard. We refine the design of the courtyard by thinking about the other patterns that would exist in the context of the courtyard pattern, such as porches or verandas facing the courtyard.
What makes this analytical method so powerful is that it does not have to rely on my experience or my intuition or my creativity. Alexander's thesis is that these patterns exist independent of any person. A space is alive because it follows a natural process, not simply because the designer was a genius. Since the quality of a design is dependent upon following this natural process, it should not be surprising that quality solutions for similar problems appear very much alike.
Based on this, he gives us the rules a good designer would follow.
One at a time— Patterns should be applied one at a time in sequence.
Context first— Apply those patterns first that create the context for the other patterns.
Patterns define relationships.The patterns that Alexander describes define relationships between the entities in the problem domain. These patterns are not as important as the relationships but give us a way to talk about them. |
Alexander's approach also applies to software design. Perhaps not literally but certainly philosophically. What would Alexander say to software designers?
| Alexander's Steps | Discussion |
|---|---|
| Identify patterns | Identify the patterns that are present in your problem. Think about your problem in terms of the patterns that are present. Remember, the purpose of the pattern is to define relationships among entities. |
| Start with context patterns | Identify the patterns that create the context for the other patterns. These should be your starting point. |
| Then, work inward from the context | Look at the remaining patterns and at any other patterns that you might have uncovered. From this set, pick the patterns that define the context for the patterns that would remain. Repeat. |
| Refine the design | As you refine, always consider the context implied by the patterns. |
| Implement | The implementation incorporates the details dictated by the patterns. |
Using Alexander in software design: a personal observation.The first time I used Alexander's approach, I took his words too literally. His concepts—rooted in architecture—do not usually translate directly to software design (or other kinds of design). In some ways, I was lucky in my early experiences in using design patterns in that the problems I solved had the patterns follow pretty well-defined orders of context. However, this also worked against me in that I naively assumed that this method would work in general (it does not). 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. |