Charlie Alfred’s Weblog

Putting Language Back Into Pattern Languages

Design Patterns have been a big part of the software development mainstream for 15 years.  They encapsulate design expertise and streamline communication about software problems.  However, they have yet to reach the full potential expressed by Christopher Alexander in A Timeless Way of Building.  This article will discuss some of the reasons for this, and what things might be done to begin to realize this potential.

Design Patterns Overview

If you are involved with software development, and you aren’t fixing Visicalc bugs or you aren’t working in COBOL or FORTRAN, odds are pretty good that you have heard about design patterns.  But just in case you are, or in the event that you are a distant relative of Rip Van Winkle, and are trying to catch up…

Erich Gamma, Richard Helms, Ralph Johnson, and John Vlissides (also known as the Gang or Four, or GoF) collaborated on the book Design Patterns: Elements of Reusable Object-Oriented Software, which hit the shelves in 1994 (yes, in 1994, books actually still hit the shelves).  The book was a monster hit as software books go, and after 15 years it is still ranked #1 in the Amazon category:

Computers & Internet -> Computer Science -> Software Engineering -> Design Tools & Techniques

In this Amazon category, its sales rank ahead of noteworthy works, such as:

o       #4  Refactoring: Improving the Design of Existing Code, by Martin Fowler

o       #18 Software Reuse: Process and Organization for Business Success, by Ivar Jacobsen et al.

o       #27 Mastering the Requirements Process, by Suzanne and James Robertson

o       #35 Rational Unified Process: an Introduction, by Philippe Krutchen

The Design Patterns book sparked a sizable movement in the software industry, and gave rise to:

o       Holding annual “Pattern Languages of Program Design” conferences since 1996 ( )

o       Compilation of 5 volumes of Pattern Languages of Program Design books

o       Publication of dozens of design pattern books, in a wide range of subjects, including: Action Script 3, Ruby, VB.Net, SQL, and Realtime Systems.

But if you have read this far, you probably didn’t need to be convinced that design patterns have had a profound impact on the way that millions of software developers work.  But what is it that really makes design patterns so effective?

Design Pattern Origins

While Gamma et al brought design patterns to the collective attention of the software development community in 1994, the central ideas were spawned nearly 20 years before, in the work of Christopher Alexander.  At that time, Alexander was a professor of building architecture at the University of California at Berkeley.  He had grown frustrated with soulless, cookie-cutter buildings that seemed not to have any life.  He contrasted them with examples of buildings and villages thoughout the world that seemed be timeless and fit in naturally, like:


Speaking of the origins of patterns, Alexander wrote:

“Our world has a structure… certain patterns of events – both human or nonhuman – that keep repeating, and account, essentially for much the greater part of the events which happen there. And indeed, the world does have a structure, just because these patterns of events which repeat themselves are always anchored in space.”

In other words, patterns grow out of events that naturally happen in a certain location.  We have kitchens because we need a place to cook and share meals; we don’t have them because we need places to store stoves, sinks, and refrigirators.

Alexander goes on to write:

“Each pattern is a three-part rule, … a relationship between a certain context, a certain system of forces which occur repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.  As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.

Design Patterns summarizes this as, “a design pattern is a solution to a problem in a context, that is given a name.  While correct, this simplification seems to lose a little in the translation.  Expressing a system of forces as a problem takes some of the color away from it, and diminishes its precision.

This is because the system of forces which match a pattern are not isolated to the pattern.  The pattern belongs to a much larger set of forces that belong to the broader problem.  As Alexander would say, patterns in a room have to harmonize with patterns in the building, which must blend seemlessly into patterns in the block, etc.  Keen awareness of the bigger picture is essential.  But before we explore this, let’s first examine patterns in the context of language.

Design Patterns and Timeless Way of Building

Software micro-patterns, like Composite and Proxy are the vocabulary of software design.  They have short, descriptive names that capture the essence of a concept or an approach:

o      “I really think we should use the Strategy pattern to design a client that can work either connected to or disconnected from its server.”

o      “Using the Composite pattern to model a file system simplifies the implementation of a recursive operation, like incremental backup.”

o      “A great use of the Proxy pattern is to take the WSDL for  a Web Service and generate the client and server stubs, to hide the details of SOAP.”

o      Given how configurable our UI dashboard will be, doesn’t it make sense to use the Observer pattern to monitor state changes for all UI elements?”

Software design patterns contain expert knowledge about how to solve a specific type of problem, and the pattern name enables developers to streamline their communication with each other.  Clearly, this is a good thing.  In this era of information overload and severe time pressure, anything that increases efficiency has d to be good.  And when it also packages up good advice in the process, then it’s even better than Life Cereal  (“Hey Mikey!  He likes it!”).

But is there more?  Should there be more?  Section 6.3 of the Design Patterns book addresses this question:

“We aren’t the only ones writing books that catalog the patterns experts use.  We are part of a larger community interested in patterns in general and software patterns in particular.  Christopher Alexander is the architect who first studied patterns in buildings and communities and developed “a pattern language” for generating them. His work has inspired us time and again.  So it is fitting and worthwhile to compare our work to his…

There are many ways in which our work is like Alexander’s.  Both are based on observing existing systems and looking for patterns in them.  Both have templates for describing patterns (although our templates are quite different).  Both rely on natural language and lots of examples to describe patterns, rather than formal languages, and both give rationales for each pattern.

But there are just as many ways in which our works are different:

1.      People have been making buildings for thousands of years, and there are many classic examples to draw upon.  We have been making software systems for a relatively short time, and few are considered classics.

2.     Alexander gives us an order in which his patterns should be used; we have not.

3.     Alexander’s patterns emphasize the problems they address, whereas design patterns describe the solutions in more detail.

4.     Alexander claims his patterns will generate a complete building.  We do not claim that our patterns will generate complete programs.

While these differences are important, there is another difference that I believe overrides them all.  This difference is captured in the following passage from Christopher Alexander’s A Timeless Way of Building (the highlighting is mine):

“Once we have understood how to discover individual patterns which are alive, we may then make a language for ourselves, for any building task we face. The structure of the language is created by the network of connections among individual patterns: and the language lives, or not, as a totality, to the degree these patterns form a whole.

Each pattern depends both on the smaller patterns it contains, and on the larger patterns within which it is contained. – And it is the network of these connections between patterns which creates the language.In this network, the links between the patterns are almost as much a part of the language as the patterns themselves.

Patterns and Language

Alexander’s reference to pattern languages gives us another frame of reference.  A useful comparison can be drawn between software patterns and another form of human expression:  written (or spoken) language.

As I said above, software design patterns (especially micro patterns like the ones in Design Patterns), are a form of powerful vocabulary.  In a written language they would take the form of:

Powerful Vocabulary



A perfect storm of mistakes killed that project.

His endorsement is the tipping point of this election.


After the news, she was as white as a sheet.

The late TD shocked the crowd like a lightening strike.

Both metaphors and similes are powerful because of how much meaning they can convey, with so few words.  They tap into popular trends (e.g. A Perfect Storm and The Tipping Point) or common experience (white sheet or an arc of lightening) for references that carry meaning.  Similarly, the name of a design pattern conjures up the problem, context, and solution.  In music, chords and tempos play a similar role (“play these 8 bars in G7, allegro”).

But unlike software design patterns, written language and music go beyond analogies and chords (of course, in fairness to design patterns, analogies and chords have also been around for a while).

Written language contains mechanisms that capture the full intent of design patterns by expressing the critical relationships between vocabulary items:

o      Sentence grammar defines parts of speech, parts of a sentence, clauses and sentences, types of sentences, and the rules for constructing a proper sentence.

o      Discourse grammar defines how a dialog or piece of persuasive writing is composed from sentences, and rules for carrying references across sentences (i.e. which male does “he” refer to in this context?)

o      A Style Guide defines rules that specify good or bad writing examples in various contexts (i.e. what is good style for a business memo is probably not for a novel).

Without these elements of grammar and style, an enormous vocabulary is not very useful for effective communication.  The converse is certainly true, as well.  The best grammar and style is of little use without a rich vocabulary.  In music, the analog is rules about composition: chord progressions, how keys match mood, meters (beats to a measure), and tempo shifts.

So here we see a familiar and practical example of Alexander’s assertion:

“Each pattern depends both on the smaller patterns it contains, and on the larger patterns within which it is contained. And it is the network of these connections between patterns which creates the language.

Toward a Language of Software Design Patterns

In order to move to the next level with software design patterns, a shift in focus is required toward the relationships in design patterns.  Here, I’m not referring to generic, abstract relationships, like: “the Command and Proxy Patterns can be combined to send client requests to a remote server.”  No, what we’re really looking for here are examples of what Alexander refers to when he says:

The quality without a name appears, not when an isolated pattern lives, but when an entire system of patterns, interdependent at many levels, is all stable and alive.”


A pattern only works, fully, when it deals with all the forces that are actually present in the situation.

So, moving to the next level requires us to examine larger problems, understand a complete set of forces, then see how a complementary set of patterns come together to resolve these forces.  A larger problem such as this could take several forms.  The following table is intended to illustrate some of these common forms, and is not meant to be an exhaustive list.

System Type







An Inconvenienced Passenger Rebooking System for an airline

Web Application



An e-Commerce site like or social network like Facebook


Specific Type


A desktop speech recognition program, such as Dragon Naturally Speaking

Product Suite



A family of interoperable products, such as Microsoft Office


Specific Type


A library that is leveraged by other products and apps, such as PureMVC

An outstanding example of how to communicate a pattern language is shown by a white paper published by PureMVC.  This 46 page paper, titled Pure MVC – Implementation Idioms and Best Practices can be downloaded from:,com_wrapper/Itemid,174/

For anyone not yet familiar with Pure MVC, it is a multi-platform open source framework for user interface applications, that implements the popular MVC (Model-View-Controller) pattern.  Originally written for Adobe Action Script, it has since been ported to over 10 other programming languages, including Java, JavaScript, C#, Ruby, and Python.

The primary goal of the MVC design pattern is to make UI code more flexible, understandable, reusable, and maintainable by separating responsibilities into three areas:

View              handle all user interaction (presentation and input events) and isolate the native windowing system (e.g. UI controls)

Model           maintain all state information related to the user’s session and communicate changes to that state

Controller   orchestrate interations between the view and model, and also with other services provided by the system used by the user.

In principle, MVC permits the View layer to be changed independently of the Model, and allows the same Model to be reused in different user interfaces.

PureMVC provides an object-oriented MVC Framework that can be used by many applications, written in many programming languages, and running on several platforms.  What is more impressive to me, is the way that PureMVC uses design patterns to achieve this.

The following table summarizes the design patterns that are used in PureMVC.  It is not possible for a short table to capture the richness of the description of forces at work in a complex UI application, and the rationale for why each of the design patterns were used.  If you are interested in this level of understanding, I strongly recommend that you download a copy of the white paper.





Consistent handling of core responsibilities across the framework

The Model, View, and Controller classes are each implemented as Singleton instances.  Each singleton manages a set of application specific helper classes (View: Mediator, Model: Proxy, Controller: Command)


Simplify the API for a complex subsystem by consolidating the entry point methods in one place

A PureMVC Façade class provides a single API to access the Model, View, and Controller singletons.


Isolate UI controls, and windowing system from the rest of the UI

Most user interfaces use a variety of complex controls: grids, trees, drop-drown lists, tabs, etc.  Different windowing systems implement these differently.  Mediators are PureMVC base classes that applications use to hide these details.


Isolate the details of interacting with data objects or application service providers.

Data objects frequently need to be reused across a set of several applications.  Proxies are PureMVC base classes that process notifications and operate on application-specific data.


Isolate interaction with the rest of the system from the UI

User interfaces, even complex ones, exist to enable user(s) to access functions provided by a system.  Commands are a clean way to define and isolate the service provider API


Detect asynchronous events, such as state changes, while decoupling the observed items from the observers.

One of the more complex forces in a user interface is when an entity must react after an event occurs.  An example is monitoring the value of a key control variable and issuing an alert when it hits a certain level.

Conclusion: An Approach To Generating Pattern Languages

What is really special about the PureMVC example is the way that the framework users can understand the whole problem, by understanding exactly how the various patterns fit into the puzzle.  This is virtually the same as how a savvy football fan understands the positions on offense and defense, and how particular formations and plays are designed to attack specific defenses (or shutdown certain offenses).

So, the key questions are:

1.      Is this a one-time, fortunate example of a pattern language in software?  Or, is this something that can be achieved repeatedly?

2.     If this can be achieved repeatedly, is it purely an organic process that depends on designers and architects who are both talented and aware?  Or, are there any things we can do to accelerate the process?

Personally, I don’t believe the Pure MVC example is a one-time phenomenon.  I have seen other examples that come close.  For example, the book by Alur, Crupi, and Malks, Core J2EE Patterns: Best Practices and Design Strategies, goes down a similar road as the Pure MVC white paper.  This book focuses on  Java Enterprise applications, and does an excellent job of explaining how a variety of higher-level design patterns are useful.  The book also shows how certain design patterns can be combined to resolve additional forces in the domain.

However, the essential difference between Core J2EE Patterns and Pure MVC is that the J2EE book is fundamentally about describing new patterns, while the Pure MVC white paper is about describing how documented patterns are being used to solve a particular type of problem.

In the final analysis, pattern languages are about the synergy that is created when patterns are used in a skillful and natural way.  Patterns are about techniques that can be reused to solve a particular type of problem.

So, I believe that this addresses the first question.  The Pure MVC white paper is not some mutation or freak of nature.  It is an excellent example of what is possible when we focus on the language of design patterns.  But what about the second question?  How can we, as an industry, start doing more of this?  After all, Alexander says that this is a natural process, not a forced one.

I believe that Alexander gives us important hints when he writes:

So, the real work of any process of design lies in this task of making up the language, from which you can later generate the one particular design. You must make the language first, because it is the structure and the content of the language which determine the design.”


A pattern only works, fully, when it deals with all the forces that are actually present in the situation.

We must account for all of the forces present in the situation, then we must resolve these forces with a harmonious set of related patterns.  Perhaps we hear what we want to hear, but this sounds like architecture to me:

o      Compexities ( and architecture challenges are closely related to forces.  If you can identify a complexity, there’s a decent chance that you can identify the forces that cause it.

o      Alexander’s approach strongly suggests that we should not consider forces (challenges) individually, but rather as a set.  In practice this is true.  Few challenges are unrelated to other challenges.  As a result, anything we do to address one challenge is likely to create new issues for other challenges.  It’s like putting up a tent alone.  You work on one tent pole at a time, but you never work on one tent pole in isolation.

o      When we examine a set of complexities or challenges, we start to consider approaches to address them.  Approaches are just a related set of decisions intended to overcome a challenge.  Design patterns are abstract sets of decisions intended to solve a problem in a context.  When we “color-in” one or a few design patterns to fit into the forces in a specific problem/context, we are proposing an approach.

But isn’t this just the type of regimented, systematic, mechanical approach that Alexander decries?  I don’t believe it is.

Alexander’s recommendations for a natural, organic solution are just that – for a solution.  He never says, or even implies, that you can’t use a systematic approach to understand the problem.  In fact, he points out specifically how important it is to understand the full set of forces in the problem and context.  “Full set” and “ad hoc” aren’t usually terms that go together.

So, if you are working on the design of a complex system, my recommendations are this:

1.      Use a rigorous, systematic approach (like complexity-driven design, or some other) to understand the problem, its contexts, and the forces that are at work there.

2.     Study these forces, and experiment as necessary, in order to understand how they are interrelated, how they vary, and how much they shape your problem.  Resolving forces with patterns means making tradeoff decisions, and you cannot make good tradeoffs without understanding the forces.

3.     Look for patterns that help resolve these forces.  Look for them in published pattern catalogs.  Or look for them in systems that address similar problems as yours, in similar contexts, than seem to be positive examples.  Or, in some cases, look to different problem domains for example.  It is possible to allow good analogies can work for you.

4.     Form your solution as a pattern language.  This will help other people to understand it.  You already know what kind of harm can occur if they work on your system and don’t understand.  Try to help them comprehend.

Special thanks go to Theoretische Informatik – Algorithmik und Logik, in the Department of Computer Science at the University of Berlin for posting the outstanding summary of A Timeless Way of Building, which can be found at:




  1. […] Putting Language Back Into Pattern Languages […]

    Pingback by Pattern Languages « Charlie Alfred’s Weblog — February 21, 2009 @ 2:21 pm

  2. Hello!
    Very Interesting post! Thank you for such interesting resource!
    PS: Sorry for my bad english, I’v just started to learn this language 😉
    See you!
    Your, Raiul Baztepo

    Comment by RaiulBaztepo — March 31, 2009 @ 8:10 pm

    • Thanks. Hope you enjoy some of the others. Architecture Stylin’ deals with a similar subject: architecture styles. And the complexity-driven development series wraps a context around ways to uncover the need for patterns.

      Comment by charliealfred — April 1, 2009 @ 10:10 am

  3. Hello !! ^_^
    I am Piter Kokoniz. Just want to tell, that I like your blog very much!
    And want to ask you: what was the reasson for you to start this blog?
    Sorry for my bad english:)
    Thank you!
    Your Piter Kokoniz, from Latvia

    Comment by PiterKokoniz — April 8, 2009 @ 4:30 pm

    • Thanks, Peter. I appreciate the compliment. The main reason I started writting this blog was to describe value modeling. This is an approach that I found to be extremely useful when working with product family architectures, where managing variability among contexts is critical to success. Since there wasn’t a great deal written about how to do this, I thought it would be good to try to share some ideas.

      Once I got in the habit of writing, I guess I just wrote about topics that seemed to be relevant to the work I was doing – architecture, challenges, patterns, product strategy, etc. To be honest, I’ve been a big beneficiary of the process; writing and editing articles has always been a very good way for me to crystalize my own thinking.


      Comment by charliealfred — April 8, 2009 @ 8:29 pm

  4. […] following essay (  explores Design Patterns, A Timeless Way of Building, and several related topics to try to […]

    Pingback by Pattern Languages | The Agile Radar — December 8, 2011 @ 1:12 pm

  5. nice have one question which design pattern is useful in social network website like facebook?

    Comment by ashish fugat — October 29, 2012 @ 1:08 am

RSS feed for comments on this post. TrackBack URI

Blog at

%d bloggers like this: