This paper is an introduction to Design Patterns and a discussion of how Alexander's and his colleagues' ideas took root in the distant soil of Computer Science. It is necessarily a sketch of my personal impressions, by no means an exhaustive analysis. I wish I had the insight to explain this all, but I am paralyzed by its depth.
Christopher Alexander helped found the UC Berkeley Center for Environmental Studies in the late Sixties. In 1978, "after a ten-year silence," according to the jacket, "... [they] are publishing a major statement in the form of three books which will, in their words, `lay the basis for an entirely new approach to architecture, building, and planning, which we hope will replace existing ideas and practices entirely'."
The resulting triptych, The Timeless Way of Building (the manifesto), A Pattern Language (the technique), and The Oregon Experiment (the result) formed a forceful and complete argument for a new theory of design, but one which cannot be said to have taken the world by storm. Indeed, Alexander's work to `rationalize' the artistic process of architecture is seen as often alienating to the practice, the exact opposite of what later awaited the introduction of `artistic' patterns to the software engineering community:
"Slightly different is the American attempt to computerize design, which is best associated with the researches of Christopher Alexander and his teaching at Berkeley. Like [Buckminster] Fuller's [geodesic] dome it is indeed very American, seeking a method technologically sophisticated, very clear, promising mechanical answers. Its deterministic purism is sympathetic to much American thought, but it hardly satisfies all American objectives."
"the act of building one of these mechanisms is more than a mechanical experiment for Fuller and his followers; it is a mystical rite, to be repeated with little variation over and over again, eternally wonderful, always complete."
--Vincent Scully, Modern Architecture , page 212
Originally, Alexander had advocated an even more mechanistic approach to design in his 1964 Notes on the Synthesis of Form ; that work laid the foundation of his quest at Berkeley.
According to Lea, Notes was an expression of a more innocent era in engineering and analysis, built upon the essential optimism of a host of postwar intellectual movements: cybernetics, systems analysis, operations research, and computing.
Notes establishes Alexander's dual concerns. He extols the virtues of traditional artifacts: their `unselfconscious' design, their adaptability and beauty. Yet he proposes to achieve such integration through formal constraint analysis. As Lea describes:
Notes includes presentation of a semiformal algorithmic method that helps automate good partitioning under various assumptions. To use it, one first prepares an exhaustive list of functional and structural constraints... The algorithms takes as input a boolean matrix indicating whether any given pair of constraints interact.... This statistical clustering algorithm arrives at subsystems by minimizing the interaction of problem requirements that each one deals with. The goal is to mirror the micro-structure that each part in a well-adapted unselfconsciously designed system would possess... leading him to argue for empirically and experientially guided analysis.
In fact, Alexander's method is less robotic than this passage makes it sound; it is conceptual kin to Louis Kahn's theories of "basic-concept-deformed-by-contextual-special-cases." Indeed, the quoted passage from Scully is his introduction to Kahn.
Why didn't Alexander declare victory with the publication of Notes ? In the years after, he saw that his theory in the hands of other architects and laypeople (even then, he was known for advocating user-driven design and the deprofessionalization of architecture) did not succeed as his own examples had. First, though, he had to put his finger on what `success' meant to him.
When Alexander and his band emerged a dozen years later, the put a name to what they considered good design: "the quality without a name." What Notes merely included as broadsides against Modern design:*
· Inability to balance individual, group, societal, and ecological needs.
· Lack of purpose, order, and human scale.
· Aesthetic and functional failure in adapting to local physical and social environments.
· Development of materials and standardized components that are ill-suited for use in any specific application.
· Creation of artifacts that people do not like
were refined into a series of essays about the feeling of that `quality' in The Timeless Way of Building . Alexander conveys his understanding as much through image and counterexample as by way of explanation. He treats it as an almost sacred, certainly transcendent goal; equal parts love and aesthetics. "Freedom, life, wholeness, comfortability, and harmony" are only a few of the ingredients to this quality.
Alexander and his colleagues clearly extol the virtues of traditional, indigenous design over `Main Street.' They are clearly inspired by the image of the European village and their fieldwork in Peru and India. They also fold in large doses of what can only be called a Berkeley consciousness of social justice and impending late '70s apocalypse.
So how, indeed, does Alexander expect to offer concrete guidance to even the most casual observer on achieving perhaps the warmest, fuzziest design goals in print?
Alexander's answer is a rediscovery and systematization of the most ancient design theory: analogy. In a A Pattern Language , he presents 253 problem-solving-processes from the scale of cities and cultures to construction and decoration. It is not an Erector set of compatible `design modules' any more than a dictionary is a toolkit for novelists. Indeed, its flexibility and possibility justify its denotation as a Language. Each pattern is a part of the vocabulary of the Alexandrian world, structured by a grammar relating patterns across scales.
Patterns share a formal structure. At every level of scale (Towns, Buildings, and Construction), Patterns include the same elements: an evocative Name, a graphic Illustration, its Context (larger-scale patterns), the Problem statement, a well-researched Solution, and Consequences guiding the choice of smaller-scale patterns. These elements are used to recapitulate a narrative process at each level:*
IF you find yourself in <context> for example <examples>, with <problem>, entailing <forces>
THEN for some <reasons>, apply <design form and/or rule> to construct a solution leading to <new context> and <other patterns>
Perhaps it makes sense at this point to excerpt an example of a design solution written in Alexander's pattern language. Note how clearly this passage evokes a solution, even without referring to the detailed explanations found in the handbook.
All 253 patterns together form a language... for example, consider the following ten patterns:
This short list of patterns is itself a language: it is one of a thousand possible languages for a porch, at the front of a house. This is the way the language, and its patterns, helped to generate this porch:
I started with private terrace on the street. That pattern calls for a terrace, slightly raised, connected to the house, and on the street side. Sunny place suggests that a special place on the sunny side of the yard should be intensified and made into a place by the use of a patio, balcony, outdoor room, etc...
To make this platform into an outdoor room, I put it half under the existing roof overhang and kept a mature pyracanthus tree smack in the middle of the platform...
I used six-foot balcony to determine the size of the platform. But this pattern had to be used judiciously and not blindly -- the reasoning for this pattern has to do with the minimum space required for people to sit comfortably and carry on a discussion around a small side-table...
The character of the porch is given by the ten patterns in this short language. In just this way, each part of the environment is given its character by the collection of patterns which we choose to build into it. The character of what your build, will be given to it by the language of patterns you use, to generate it.
Finally, before embarking on a tour of Alexander's patterns, it is worth keeping in mind that Patterns is only one language among many; separate the design theory from the particular design prescriptions. Patterns , in fact, is strongly targeted as a language for developing villages and intimate cities, usable by laypeople to design their own homes and communities.
We begin with that part of the language which defines a town or community. These patterns can never be "designed" or "built" in one fell swoop--but patient piecemeal growth, designed in such a way that every individual act is always helping to create or generate these larger global patterns, will, slowly but surely, over the years, make a community that has these global patterns in it.
At the `top-level,' Alexander wants to world to have self-supporting independent regions. After laying out rules for the distribution and structure of settlement and countrysides, they proceed to seed it with a mosaic of subcultures. Each of these, in turn is built from identifiable neighborhoods, ideally communities of 7,000. Within them, they advocate construction of a web of public transportation along ring roads to form a web of shopping, a network of learning, and so on.
Here, too, we see trademark Alexander axioms of design, meticulously researched and defended: four-story limit, nine percent parking, and small public squares. This is the kind of work that won Alexander and his colleagues the first-ever AIA medal for architectural research.
At this scale, Patterns also describes how to design housing clusters, road networks, workspaces, and adaptations to the lifecycles of the community. In addition, we also have prescriptions for more specific community services: beer hall, corner grocery, night life, and sleeping in public (no churches, though...)
This completes the global patterns which define a town or a community. We now start that part of the language which gives shape to groups of buildings, and individual buildings, on the land, in three dimensions. These are the patterns which can be "designed" or "built"--the patterns which define the individual buildings and the space between buildings; where we are dealing for the first time with patterns that are under the control of individuals... who are able to build the patterns all at once.
This, the meat of the book, reveals Alexander's identification of the forces that influence the plan and envelope of buildings: their functions, siting, role in community life, contextual relationships to other buildings, and diversity of form.
The next, and last part of the language, tells how to make a buildable building directly from this scheme of spaces, and tells you how to build it, in detail.
Once again, Alexander's team argues with well-researched economic, ecological and engineering principles. They describe a style of building based on compressive, ultralight concrete structures easily buildable directly by the occupants. They encourage a hands-on interactive approach disdaining blueprints in favor of stakes in the ground, and prototype-driven feedback by stiffening (formalizing) structures gradually.
Considering all these patterns together, it becomes clear that there is a pattern to these patterns. The problems they choose to address are from a few general categories: how to adapt to (Alexander's perception of) human needs, how to keep towns ecologically balanced, and how to build social justice into the town. The problems they choose to so address are as likely to be solved by dint of exhaustive research, survey, simulation, or analysis as ad hominem rhetoric. Finally, they make no pretense of crafting A Pattern Language into anything resembling a formal grammar; there is nothing stronger than intuition to guide the pattern-driven designer.*
Herewith, a few selected examples:
Metropolitan regions will not come to balance until each one is small and autonomous enough to be an independent sphere of culture.
This is the root pattern, #1, and it's double-starred to boot; this means that they think it is an extremely significant invariant. On what basis?
There are four separate arguments which have led us to this conclusion: 1. The nature and limits of human government. 2. Equity among regions in a world community. 3. Regional planning considerations. 4. Support for the intensity and diversity of cultures.
In support of such grand arguments, they quote from biologists, one-world-government buffs, anti-nationalists, and an especially strident:
4. Finally, unless the present-day great nations have their power greatly decentralized, the beautiful and differentiated languages, cultures, customs, and ways of life of the earth's people, vital to the health of the planet, will vanish.
Furthermore, this inauspicious start smacks of pseudo-science. They open with a mathematical argument about the growth rate of person-to-person relationships (N 2), but there the empiricism stops:
Naturally, when N goes beyond a certain limit, the channels of communication needed for democracy and justice and information are simply to clogged, and too complex; bureaucracy overwhelms human processes.
There are other patterns where they reuse these arguments for more concrete conclusions: a logarithmic distribution of towns or the sociological evidence for community of 7000.
There are few people who do not enjoy the magic of a great city. But urban sprawl takes it away from everyone except the few who are lucky enough, or rich enough, to live close to the largest centers.
It is clear from that Alexander's pattern language is not intended to allow users to build Los Angeles, New York, or Paris. There is one pattern, though, that does address this, and it is a notable example of a separate class of evidence/research that they use.
...cities with more than 50,000 people have a big enough market to sustain 61 different kinds of retail shops and that cities with over 100,000 people can support sophisticated jewelry, fur, and fashion stores. He shows that cities of 100,000 can support a university, a museum, a library, a zoo, a symphony orchestra, a daily newspaper, AM and FM radio, but that it takes 250,000 to 500,000 to support a specialized professional school like a medical school, an opera, or all of the TV networks.*
From this, they decide upon an egalitarian maximum of 300,000 per downtown, to help keep such excellence accessible, a conclusion in keeping with the overall flavor of their biases.
There is abundant evidence to show that high buildings make people crazy.
This is perhaps Alexander's most famous dictum. It is certainly an archetypal pattern: first the rhetorical attack
High buildings have no genuine advantages, except in speculative gains to banks and land owners. They are not cheaper, they do not help create open space, they destroy the landscape, they make life difficult for children, they are expensive to maintain, they wreck the open spaces near them, and they damage the light and air and view. But quite apart from this, empirical evidence shows that they can actually damage people's minds and feelings. [Insert picture here libeling the Transamerica pyramidal tower as 1984 's Ministry of Truth]
Then the marshalling of diverse researches: a British Medical Journal study correlating mental disturbance with the height of people's apartments; the Canadian Public Health Association; Danish studies of children's friends vs. height; increased crime rates; and even a children's ditty from Edinburgh mocking the `skyscraper wean.'
The only devices held in check in this attack are the survey (used to advocate promenades, workplace privacy, window-siting preferences, noise levels,...) and the simulation (economic analysis of construction density, plaza scaling, nine percent parking).
They then cap their wave of fury with a frothy prescription, and a call for action citing subsidiary patterns to be investigated as remedy:
In any urban area, no matter how dense, keep the majority of buildings four stories high or less. It is possible that certain buildings should exceed this limit, but they should never be buildings for human habitation.
Some buildings have column and beam structures; others have load-bearing walls with slab floors; others are vaulted structures or domes, or tents. But which of these. or what mixture of them is actually the most efficient? What is the best way to distribute materials throughout a building, so as to enclose the space, strongly and well, with the least amount of material?
Finally, we encounter the type of pattern that explicitly solves a posed question. Here, analytical and experimental skills come to the fore; in a later age, we would be treated to extensive computer design models. They use this tactic when planning parking, transportation, minibus services, road layout, and choosing materials and techniques; almost any problem tractable to conventional systems analysis or operations research.
These are the patterns that most strongly infuse Patterns with the aura of scientific validity. And yet, these techniques are often used to reach the same, moralistic judgements as the rest: a blind rejection of automobiles, veneration of selected materials and construction methods -- all in all, a nagging sense of consistency, stifling true diversity in design.
Designing software for parallel computers is hard. Right now, there is immense competitive pressure to harness the power of such machines, a process significantly more complex than for programming single computers. So far in the history of parallel software design, scientific codes (fluid dynamics, numerical analysis, climate simulation...) have been hand-crafted for particular machines and problems, at immense expense. Furthermore, it is not clear that programmers are properly addressing the concerns unique to parallel processing: synchronization, correctness, load balancing.
In the spring of 1993, I coined the name Archetypes to denote a system of software construction already gestating in the parallel software community. We wanted to provide some systematic way to teach parallel and sequential programming constructs to undergraduates, professionals, and skilled sequential programmers.We wanted to provide a systematic editorial framework for capturing designer's rationales and experiences n various machines, algorithms, and problem types.
The Archetype method offers guidance at three scales (Archetype, Application, and CaseBook) by recapitulating a standard form:
This Five-Fold Way was designed to root the reader in a genuine grammar, an archetypal language that guides the entire design process from concept to code. It was implemented in the eText "electronic Textbook" project.
At the top level, we present a catalog of Archetypes, generic problem-solving frameworks. For example, many problems can be solved by Divide-and-Conquer; this Archetype is appropriate for any problem that can be split into pieces and solved by combining the solutions to those pieces. Other Archetypes are appropriate for Matrix Operations, Mesh Computation, Dynamic Programming, Spectral Methods, and so on.
The narrative form of an Archetype does not concern itself with parallel vs. sequential concepts, or with particular problems of its type. It is intended to unify all examples of that Archetype into a common algorithmic framework.
We refine an Archetype to solve a particular problem with an Application. Now, we substitute the creative step that lets us, say, use Divide-and-Conquer to sort lists or perform a Fourier Transform. We still do not address machine concerns, but we do take the opportunity to explain which problems can and cannot be solved with each Application. Again, we use the same narrative form, except for a more specific form of the archetypal solution technique.
Finally, at the third level of scale-refinement, we arrive at CaseBooks, particular examples of Applications rendered with a particular programming language for a particular kind of parallel or sequential machine. Only at this level do we separate parallel from sequential, thus minimizing the retraining effort.
Taken together, the eText project offers a much more formal notion of an Archetypal Language, in which all of the parts must fit grammatically. This handbook attempts to play the same catalytic role as Patterns ,by empowering "layprogrammers" to design and implement parallel codes that work reasonably well. Furthermore, just as Alexandrian patterns encode a strong bias towards a particular social world-view, Archetypes are mainly useful to developers of scientific codes, since its biases do not work for business simulation, game design, or consumer `desktop' applications.
Object-Oriented Programming, on the other hand, is particularly strong at designing those kinds of application that interact with the real world: games, business processes, and productivity applications. Where `conventional' programming languages are like recipes, dictating a rigid series of instructions that mix & mash bits of data, OO uses objects to bind together particular data and the operations on it. So, it makes a clear analogy to a room full of people, each expert at doing one thing with only whatever knowledge that person has; things get done as people ask each other to compute certain things for them. This neat encapsulation of behavior stands in contrast to the traditional `spaghetti' code of procedural programming.
Object-oriented programming also holds up well in architectural metaphors. Objects can be assembled in complex structures just as architecture does, but with a time dimension that captures the ballet of messages and dynamic rearrangement of objects.
Object-oriented programming also holds up well by analogy to the real world: you can model a pencil as a pencil, a car as a car, and an invoice as an invoice. Furthermore, object-oriented programming lets us organize hierarchies of similar classes of objects: a Ford is like a car, but with slightly different colors; a car, in turn, is like a Vehicle, but with four wheels and confined to the ground. We can introduce abstract concepts, like Shape, to hold the behavior common to particular Shapes, like Circles, Rectangles, and Lines.
On that admittedly sketchy primer, we introduce Design Patterns , by Gamma, Helm, Johnson, and Vlissides. DP is an conscious attempt to bring Alexander's design theories over to the insubstantial world of software design. A core cult formed around Alexander in the early 90s, that has blossomed into a movement in software design, with its own books, conferences, and constituency.
Alexander's ideas found a comfortable home because many designers already had proposed convergent schemes (Archetypes, any of the systems mentioned in Lea's paper), and because software design has always been in an intense soul-searching mode to find an established discipline to look up to. In the 1968, Software Engineering was coined by the faction inspired by civil and electrical engineering, with its statistical controls, standardized models, and absolute faith and correctness. Only recently has a new generation advocated adding more art to our pseudo science by advocating Software Architecture. As a professional metaphor, it works on several levels: as a client-services model, as an artistic pretension, as a central coordination point for the "construction" process, and a belated concession that there is some nameless quality that separates elegant software from the rest.
In DP , each pattern is defined by its name, intent, motivational example, application context; it provides a list of participants, collaborators, implementation techniques, and most important, consequences. Finally, each pattern is also indexed by its known uses in well-known pieces of software (which Alexander can evoke with a single photograph).
In assembling an OO system, an architect has to populate a toolbox with a class hierarchy of useful widgets: buttons, sounds, Customers, Lists, Shapes, etc. To begin building a working machine, a designer has to instantiate widgets from his toolbox and wire them up to interact with each other just so. DP identifies several Creational patterns to guide this process.
Prototype is a pattern for copying a prebuilt part, like using a one-inch, purple circle. Singleton crops up when you want to make sure there is only one of something, like a Printer object that needs to correspond to a physical printing device.
Other techniques help you decouple a particular design from a particular implementation: a designer can ask an Abstract Factory for a window, and it will provide a different kind of window on a Macintosh than on a Windows PC. A Builder can encapsulate a more complicated process of building a subassembly built out of several objects.
Parts in hand, the designer has to wire them up so that each pair of interacting objects can locate and talk to each other. Structural patterns suggest possible relationships between multiple objects. An Adapter may serve as an intermediary, translating requests between objects. Composite objects let you combine several pieces together and treat them as one: grouping four Lines into a Square, for example; both the object and the composition have a location, a color, a pen width, and so on.
Finally, there are patterns that help you categorize objects into hierarchies and simplify the interactions between them. A Command can encapsulate a user's request so that it can later be undone; an Iterator can let another object walk through a List or other kind of container. An Observer will notify its subscribers when a particular event happens, like a change in a stock price.
Chain of Responsibility is one of the deeper behavioral patterns; it raises some question as to who's in charge?
A designer sets up a chain among objects that can all react to certain message in a delegation hierarchy. So if I have a picture, and all of the shapes are in a chain and willing to respond to a mouse-click, the CofR will automatically forward the click to the object I was pointing at. Or the keystroke, or the change-color command, etc.
That's an inversion of control : this pattern isn't controlled by the objects the designer supplies; it runs the show and calls the designer's objects at its convenience. What this means is that we may have possibly changed the nature of "patterns"; originally we made clear that patterns are not plug-and-play Erector sets; but here is a pattern that arguably is a fill-in-the-blanks solution. It is as if Alexander stepped out of writing patterns for building and started dictating patterns for living. And in software, we can dictate those rules; we can fiddle with both sides of the equation to get a fitting design. This may or may not be an insight in to software design patterns. In the literature, such an inverted-control structure is called a framework ; we can have well-designed frameworks for securities trading, for example, and thus plug in new derivatives or stocks on the fly. Such prepackaged designs are immensely valuable, but very difficult to build well. Hence, the area of research that asks, can patterns generate frameworks? Can we use patterns not just for finished artifacts, but to build another layer of more concrete design tools?
Obviously there are some deep connections between these three design theories. Each attempts to take advantage of analogical reasoning, tapping the human power to make connections between the particular and the general, the occasional insight between two seemingly different circumstances. To varying degrees, these example-driven languages offer a structured design space to explore, a formal guides to building "harmonious" combinations, and hidden agendas that imply value judgements of the suitability and success of various artifacts.
We see that one common feature to making such catalogue-reasoning tractable is separation of concerns, usually by scale. At each stage of the design process, only a clear subset of the patterns are applicable candidates for the particular context. With Patterns and Archetypes, there is clear scale refinement; in DP , patterns exist at varying levels of abstraction.
The opposite side of this coin is that all of these methodologies are very strongly consistent at every level. The same narrative form is reprised, the same structure aids navigation, and the contexts of sub- and super-patterns constrains the search for compatible design elements.
Alexander has the advantage of producing only one level of artifacts (buildings in a community) with a single metric of success (the quality without a name). In DP or Archetypes, there are no clearly articulated goals or principle of Good Design, only Good Techniques. Furthermore, software patterns cannot be grounded in reality the same way; they often take on the computer scientist's tendency to `go meta' at the slightest provocation, and are (ab)used to produce products (software) and meta-products (frameworks, toolkits).
Each of these methodologies wants to be supported by a process that captures the essence of the design rationale. In much the same manner that Alexander rejects blueprints and sterile plans, software needs some mechanism for recording the design process beyond its static rendition in programming code. The notion of a pattern language immediately raises the level of discourse immensely by providing designers with a powerful vocabulary for naming and managing the forces shaping their design [see the Appendix for reactions].
All three of these methods also place a premium on celerity, flexibility, and adaptation. Alexander advocates intimate, hands-on design, on-site and immediate. He wants construction to move gradually and adapt to its users; a paper pattern-design is unfinished, indeed incorrect, until it is built, modified, and gradually set in place as a finished artifact. Archetypes, too, place a very strong emphasis on quick initial design solutions that still leave enough room and flexibility for continuous improvement (in performance, storage, granularity, etc). The entire field of OO software development was created to enable Rapid Prototyping and easy, flexible modifications to the object model-of-the-world and behavioral isolation. In this respect, too, there are strong common impulses in each design methodology to fire first, and aim later.
Finally, something has to be said of the way each of these methods incorporates its design biases. These languages cannot be used to generate all possible artifacts; indeed, they can only be used to produce a vanishingly small subset that conform to some hidden agenda of the pattern-compiler. With Alexander, it is at least overt; with Archetypes we do not have a clear success metric that would indicate which designs can be generated by an Archetypal language. DP is the most dangerous, since it professes no design agenda at all ("no agendas here, just a bunch of us little ol' tools..."), which only means we have no idea what its scope is.
We can't draw any conclusions yet but we can highlight several challenges to the continued evolution of this design-theory-without-a-name.
It is important for any language and grammar to explain what kinds of expressions can be produced; pattern and archetypal languages offer no such guidance yet, simply because we do not know the design scope of our artifacts (how to classify software, or buildings). Knowing the completeness of our languages would be a landmark step towards validating these methods.
Since patterns gain their power by restricting our attention to generating "good" designs, it is important to know how to retarget them to a different subset of "good". For example, architects could have much more faith in Alexandrian patterns if there were similar volumes for generating Los Angeles and New York. A powerful design theory should be flexible enough to help us design gated suburbs, shopping malls, fragmented communities, skyscrapers, and inhuman scales -- value judgements should be in the hands of the designer rather than the tool.
Finally, the greatest challenge to these methods is the lack of any design history for documenting, reusing, and sharing patterns in the design process. We need new kinds of tools and documentation techniques to identify patterns and systematically reconsider pattern-decisions.
Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A Pattern Language . Oxford University Press, New York, 1977.
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Systems . Addison-Wesley, Reading, MA, 1995.
Doug Lea. "Christopher Alexander: An Introduction for Object-Oriented Designers" in Software Engineering Notes , ACM SIGSOFT, vol 19, no 1, p 39, January 1994.
Vincent Scully, Jr. Modern Architecture: The Architecture of Democracy , revised edition. George Braziller, New York, 1994
Christopher Alexander. Notes on the Synthesis of Form , Harvard University Press, 1964
Christopher Alexander. The Timeless Way of Building . Oxford University Press, New York, 1979.
Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, and Shlomo Angel. The Oregon Experiment . Oxford University Press, New York, 1975.
Ralph Johnson. "Documenting Frameworks using Patterns" in Proceedings of OOPSLA'92, ACM SIGPLAN, 1992.
Internet Mailing List, patterns-l for discussing Gamma, et al.
Richard Dawkins coined the word Meme to describe ideas. Quoting from The Blind Watchmaker (p157) he says: "..I speculated that we may now be on the threshold of a new kind of genetic takeover... The new replicators are not DNA and they are not clay crystals. They are patterns of information that can thrive only in brains or the artificially manufactured products of brains -- books, computers and so on. But, given that brains, books and computers exist, these new replicators, which I call memes to distinguish themselves from genes, can propagate themselves from brain to brain, from brain to book, from book to brain, from brain to computer, from computer to computer. As they propagate they can change -- mutate."
Personally, I think Design Patterns are closer to memes than blueprints.
-- Bill Birch <birchb@sydney2.world.NET>
I have watched this list with interest ever since I discovered it a week or so ago. Patterns in design seems to be such an obvious metaphor that I guess we can all be somewhat surprised that no one thought of them in the software engineering domain sooner. It is also somewhat surprising that for some, the concept has been adopted with such a religious fervor. In spite of this, I am in the process of trying to get my organization to adopt a pattern based approach to software development.
-- bhorton@vegas.irs.gov
One of the great failings of Computer Science is its lack of any kind of design studio, where students are taught how to solve real-world software problems in a variety of styles. Most students come out with a grasp of only a few styles, and hold the engineer's belief that there is only one true solution technique for each problem. Worse, most designers are not aware enough to realize how tightly they are bound by their particular style.
The nascent discipline of Software Architecture recognizes a diverse set of styles, but has not yet proposed a framework for discussing how they are similar or different. I believe that we can make some headway by separating out the concerns a designer faces, and showing how a judicious choice of concerns can be recombined to generate the various traditional schools of design.
One can imagine separating out Data, Process, and Control. Data-centric designers use databases and mainframes to process large files; process-centric designers write algorithmic descriptions of what happens; control theorists manage the flow of instructions between modules and computers on a network (controls enforce rules, not by running a particular recipe, but by asserting some fact and maintaining it (e.g. "there is only one printer")). Please see the attached essay for a diagram of its effects and a short elucidation of this model.
In Lea's paper, he parenthetically notes:
(Wolfe [From Bauhaus to Our House ] provides a breezier account of some of this territory, but focusing on the schools and cults of personality found in modern architecture, that luckily have few parallels in software engineering.)
Unfortunately, SE is positively overrun with design cults, most of them as damaging as any in the Modern period. Influential writers and theoreticians are commonly promoted to practical design gurus in a marketplace desperate for the Next Big Methodology. Design methods hypothesized by their creators in the small, with obscure graphical notations overnight explode into full-blown CASE (computer-aided software engineering) tools, which bring all of the mind-numbing, strait-jacketed, acontextual design theory to the developer. Suffice it to say there are many, many more parallels between architecture cults and software cults...