How to Use the Force to Take Advantage of Design Patterns

eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

/images/stories/70×50/bug_knowledgecenter_70x70_(2).jpgDesign patterns did not begin with the “Gang of Four” (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) and their book “Design Patterns: Elements of Reusable Object-Oriented Software.” The Gang of Four (GoF) had source material. The source I am referring to is a non-software book entitled “The Timeless Way of Building” by Christopher Alexander. It is a book for architects – the kind who design art museums and skyscrapers, etc. This is largely understood to be the book that the GoF used as their starting point. What I find curious is how very differently these two books explain patterns.

Two Books: Two Different Views

The GoF’s book presents patterns as “reusable software” (which would, logically, include reusable implementation), whereas Alexander talks about patterns in terms of their “forces.” His patterns contain little in the way of measurements, materials, stress graphs or the like – things you would expect a book on architectural “solutions” to provide.

It’s interesting to note that patterns seen as “pre-rendered designs you can reuse for your solution” are not frequently very useful for most of the developers I talk to. In fact, for some, patterns have come to take on a bad reputation. It’s usually of one that includes the notion of over-design and unneeded complexity, accompanied by performance problems.

I think patterns are enormously useful. But I find that Alexander’s original view of them tends to be the better way to think about them. His is the better way to get value from them.

What Is a Force?

So, what’s a “force”? Consider the following analogy: Pick up a piece of 8.5×11-inch paper. Set it on a smooth surface directly in front of you. The paper has a nature. It has weight, a certain tensile strength, etc. The table also has a nature, which includes a coefficient of friction. These are forces of “context.” They are the circumstances of the domain within which we work. Tissue paper, or a rough surface, would create a different context within which we might find ourselves working.

Now, place your fingertips on either side of the paper. Slide the edges toward one another. This is an action you are taking that acts upon the context. You could do other things to the paper: You could cut it, tear it, crumple it or set it on fire. These actions represent our decisions about how best to achieve a given end. They are forces of “implementation.”

If you press the edges of the paper on a smooth surface as I suggest, the paper is likely to form into an arch. An arch has characteristics as well: a certain strength and a particular shape. It also has tendencies that are different than the paper had when it was sitting flat. These are the “consequences” of the implementation forces that you applied to the context you were given.

Patterns as Reusable Wisdom

Forces of Context, Implementation and Consequence: Each pattern captures wisdom about the choices we make, why we make them as we do and the results we achieve through design. They are not “reusable solutions” so much as they are reusable wisdom about what we choose, why we choose it, and what happens next. When we consider patterns this way, four good things happen.

First, we see the actual implementations in the GoF book not as the patterns, but merely as examples of the patterns in action. This means that other, perhaps more advantageous, implementations are possible. Think of implementing a Strategy Pattern with delegates, or with constrained generics, or with C++ templates. How you implement a pattern can totally change how it performs, how much runtime dynamism it provides, how you test it and whether your design is re-entrant, etc.

Second, we do not have to settle on “the” definition of a given pattern. As people find more interesting and useful ways of implementing them, there is room for us to share the wealth. I have found that discussions of patterns as “solutions” tend to devolve quickly into pointless flame wars.

Third, patterns as collections of forces become a professional language of design. Language must communicate, adapt, grow and change without losing consistency. Solutions solve, but forces give us a way of communicating what we know, expect and believe.

Fourth, we don’t expect them to replace our own judgment. Rather, we expect them to give us useful wisdom that helps us to judge better. Frankly, I don’t want to be replaced by a process. I like solving problems. I just want to feel confident that I know what I’m doing.

Check out the pattern repository I’ve been working on. It lays out many of the patterns in just this way. Take a look and let me know what you think! If you like, you can also contribute what you know about this pattern or another, and help to enrich the professional language of design we hope to share.

/images/stories/knowledge_center/cover_bain.jpgScott L. Bain is the author of the book “Emergent Design: The Evolutionary Nature of Professional Software Development“.

/images/stories/heads/bain_scott70x70.jpg Scott L. Bain is Senior Consultant at Net Objectives. He has more than 30 years of experience in the software industry. He teaches courses and consults on design patterns, refactoring, unit testing and test-driven development. He is a frequent speaker at developer conferences. Together with Alan Shalloway, he pioneered the integration of design patterns in agile environments. Bain can be reached at slbain@netobjectives.com.