Columns

Design patterns take cue from architecture

• By Jack Vaughan
• July 13, 2001

The story goes that Frank Lloyd Wright's mother placed a mobile in his crib when he was just an infant. Hanging from a wire that traversed the crib were three basic figures of geometry -- wooden blocks shaped as a pyramid, a cube and a sphere. From this, one can guess, the architect Wright gained the design patterns upon which he'd build his great legacy. Ed Note.

This is mentioned here because the concept of "design patterns" continues to gain currency among software theorists. Oddly perhaps, the theory of design patterns, which suggests there are established and reusable forms available to solve problems with distributed systems, did not arise from the ranks of object-oriented methodologists. Instead, it comes from the world of architecture. A single individual is cited repeatedly when design patterns are discussed. That person is Christopher Alexander, a British architect who has taught at the University of California at Berkeley. You will see his name over and over in the indices of new software tomes.

Alexander contends that common features -- or patterns -- can be abstracted from successful buildings that appear in many cultures in many epochs, and he has tried to create a pattern language for specifying and connecting these patterns. His texts, "A Pattern Language" and "The Timeless Way of Building" (Oxford University Press, 1977 and 1979), champion the cause of organic design. Alexander does not try to rigorously define "patterns," but he does attempt to use a theorematic approach. Many have seen in his overarching analysis a spirit kindred to that of object-oriented software architects. Interest in Alexander could accelerate next year when his long-in-press opus, "Nature of Order," is scheduled to appear.

Alexander's architectural design patterns as applied to software hit a stride of sorts in the early '90s OOPSLA conferences where more and more sessions considered issues of software design patterns. Lately, patterns have gained their own special conferences such as PLOP and the more trendy sounding EuroPLOP. Now there is a chorus of books that echo Alexander's song. Recently at hand are Thomas Mowbray's and Raphael Malveau's "Corba Design Patterns" (Wiley Computer Publishing, 1997) and Richard Gabriel's "Patterns of Software" (Oxford University Press, 1996). Also of note is "Pattern Languages of Program Design" (Addison-Wesley, 1996). And don't forget "Design Patterns" (Addison-Wesley, 1995), a highly-touted text by Erich Gamma et al. This popular book did a lot to get the concept of software design patterns over the conceptual hump and was successful enough to get the term "design patterns" into as many new books as I've had hot lunches lately. Actually, one really can't describe Erich Gamma's co-authors (Richard Helm, Ralph Johnson and John Vlissides) as "et al." In fact, they are notables heralded as the "Gang of Four."

As I recall, my first encounter with Alexander's idea of pattern languages came via Tom DeMarco's and Tim Lister's "Peopleware" in 1987. Like many others I was struck by "Peopleware" which, with its indictment of cube-crazy office managers, authoritarian project managers and "furniture police," kind of set the stage for the critical thinking of Dilbert, now the most famous software practitioner of all time. (To read about Tom DeMarco's latest book, see "DeMarco on 'The Deadline,'" p.14.)

In his introduction to "Design Patterns," Unified Modeling Language (UML) co-originator Grady Booch cites Alexander and his colleagues as possibly the first to propose the idea of a pattern language to design building and cities. Booch and others see a very useful theorem-based method at work in Alexander's texts, something concrete enough to keep software design patterns from wandering into the murky realm of deep theory.

Why is it said that Alexander presents his ideas via a theorematic approach? Because he generally presents patterns as "entries." Entries consist of solution names, examples, context, problems and solution construction suggestions. As his interest is architecture, he may describe an Arabian bazaar or a British cathedral. Although building Common Object Request Broker Architecture (Corba) applications is the goal, a similarly consistent method is applied to customary distributed computing problems in "Corba Design Patterns" by Mowbray and Malveau. The authors present the bulk of the book in a series of design pattern templates which describe solutions they have discovered in their work. And they are experienced. The authors, one the principal scientist at Mitre Corp., the other a technical staff member at Concept 5 Technologies, have both led Corba workshops and concluded that people don't want esoteric theories. The pattern templates they submit comprise (among other things) statements of most applicable scale, solution type, solution name, intent, benefits and consequences. Their earlier work, "Gamma et al.," also presented their ideas in a formulaic manner. Their pattern form roughly described includes context, forces, a solution, consequences, examples and implementation suggestions.

The authors of "Corba Design Patterns" set out the long-term goal of design patterns research. It is to provide an architectural handbook for software engineers akin to an electronics engineer's handbook or a civil engineer's handbook. For that matter their work is like an algebra book with theorems and what not. And therein lies an obvious limitation. Some designers will have no better luck building a system from design patterns than they will have building a system based on "Modern Algebra Book 1." Still, these authors deserve credit -- while they have concluded that esoteric theory is unimportant, they still are willing to grapple with non-esoteric theory.

Pattern pitfalls

Most of the authors advocating design patterns know the pitfalls of political correctness. So they present design patterns not as dogma but as a catalog of useful solutions for building distributed systems. And, as a group, the design patternists, like most software experts are a (usually) clever and (sometimes) witty bunch. In their estimation, a design pattern is a solution to a design problem. More importantly, it is a reusable solution applicable to a range of problems. Change and complexity, Mowbray and Malveau admit, are the primary forces to resolve in system-level architecture. Gamma and crew similarly admit that a design pattern language for software development may never be achieved. For his part, Richard Gabriel, who takes some amount of pages to consider the failure of his own company, Lucid, also looks critically at Alexander's work. For their parts, DeMarco and Lister pretty much stick to Alexander's comments on office design and furniture in "Peopleware," not making big leaps in terms of Alexander's applicability in the software realm.

Of course Corba -- or any standard you can reference -- is a design pattern. People doing early distributed system work kept coming up with something that finally came to be known as an object request broker. People wondered why they should design it again and again from scratch especially when its point is to connect diverse systems. Anyway, the "A" in Corba stands for "architecture," doesn't it?

What Alexander's band of disciples purvey could lead to a practical method. Again, Alexander does not promote top-down design dogma. He instead suggests that global patterns arise from patient growth. Software industry veterans are familiar with growth -- there is, for example, "spaghetti code." But patience is less familiar in software circles.

The search for a simple repeatable method of notating and handling problems is not new. Today's UML and Object-oriented Process, Environment and Notation (OPEN) are the latest attempts to produce a lingua franca for design. Although he lived long before the advent of software, Enlightenment Era German scientist and philosopher Leibnitz also set this as general goal for his notation of calculus and for his stranger yet concept of "monads" (roughly defined as indivisible entities that are basic in this Universe). A more pertinent, but less sublime, instance of design pattern efforts is represented by the work of Taligent. In fact, Erich Gamma is senior engineer at Taligent. This IBM arm has been a fount of object-oriented thinking, and useful to IBM's efforts to rationalize its vast computer portfolio. But, as a stand-alone entity, Taligent has been a disappointment in the market.

Danger: Analogy!

As experienced application development managers are acutely aware, analogies can be easy and dangerous. But some familiarity with design patterns thinking will probably prove useful as new projects are considered. There will be a backlash against any programming paradigm that gains popularity, but this doesn't detract from its potential value. In fact, many of the design pattern advocates are quick to admit the difficulties of successfully using patterns. One problem is that the pattern is only as clearly communicated as the writer's talents allow. The ability of a pattern to teach is no less sure than the ability of any college text to teach. Again, as they are an intelligent lot, design pattern advocates admit this. One can even find "Anti-Pattern" pages when surfing for patterns on the Web.

Here's a thought on the limits of analogies: Note that the vendors that pitch object software have often turned to the hardware industry for relevant analogies as they make their pitch. "You know," they might say, "in the hardware industry they have already solved this problem of reusable components." A trade press writer who has sat through as many semi-conductor pitches as software pitches can tell you that the hardware people in turn also suggest the grass is greener on the other side, and the other side usually is the building trades. Meanwhile, the trades people can tell you the work they must do to jerry-rig architect's blueprints into real buildings. Let's recall, Christopher Alexander's primary goal is to improve buildings and cities, not software design.

For his part, architect Frank Lloyd Wright, although he looked for inspiration in other cultures and times, only occasionally pursued the concept of reusable components. In my youth, I had a small adventure working on the maintenance crew of his greatest public creation, the Johnson Wax building in Racine, Wis. Talk about spaghetti code and "year 2000 problems!" The building's bricks were an entirely unique size and, rumor in the maintenance crew had it, there was only a single brick factory still in existence with the proper brick mold for replacement parts. The glass tubing that comprised the building's windows could be obtained from just a single source. Wright would design things right down to the furniture, which you won't see in Staples, but can find in the Metropolitan Museum of Art's collection. Some patterns, I guess, just like those glass tubes in the Johnson Wax building, were made to be broken. Nevertheless, they still are worthy of study and consideration.