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
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.
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,"
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.
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.
Ed. Note [January 1998] : In recent study the author has learned
that the story of Frank Lloyd Wright and the mobile in the crib may not be true.
His mother surrounded the infant Wright's crib with etchings of European catherdals,
as described in "Frank Lloyd Wright: Maverick Architect," by Frances A Davis .At
the age of seven, he was given Foebel blocks by his mother.