Design Patterns — Coming Full Circle

This is Part One of a two-part blog series related to design patterns in architecture, software engineering, and our work at Flux. Check out The Flux Patterns for Part Two.

Architecture Inspires Software: Design Patterns

Christopher Alexander, an Austrian-born architect, had a simple, elegant idea. His idea was that people should name and describe solutions to common problems in architecture. He called this a ‘design pattern’.

Christopher Alexander described 253 of these design patterns in his seminal book A Pattern Language, published in 1977, that covers everything from macro to micro design. On the macro end he describes patterns in regional and town planning such as “Pattern 3: City Country Fingers” and “Pattern 52: Network of Paths and Cars”. In the middle of the spectrum he describes the relationship between buildings, for example “Pattern 101: Building Thoroughfare” and “Pattern 106: Positive Outdoor Space”. On the micro end he describes individual spaces and how to make them livable and delightful, using patterns such as “Pattern 159: Light on Two Sides of Every Room” and “Pattern 201: Waist High Shelf”.

Pattern 159: Light on Two Sides of Every Room
Locate each room so that it has outdoor space outside it on at least two sides, and then place windows in these outdoor walls so that natural light falls into every room from more than one direction.

All 253 patterns when used together, in Christopher Alexander’s words, “create a coherent picture of an entire region, with the power to generate such regions in a million forms, with infinite variety in all the details”. Moreover, a practitioner needn’t focus on all 253 patterns at once — a smaller sequence of patterns can be used as a pattern language to focus on a smaller part of the environment, say a single building or even a single room within a building. In short, the design patterns, whether taken together or individually, articulate guidelines that can be reused for a customized design.

Fast forward a decade from the initial publication of A Pattern Language to 1987, when two computer scientists, Kent Beck and Ward Cunningham, inspired by the work of Christopher Alexander, began experimenting with applying the idea of design patterns to programming. They presented their work at the OOPSLA conference (Object-Oriented Programming, Systems, Languages & Applications), subsequently sparking a new school of thought in the software engineering community.

Over the next few years these ideas gained traction, and in 1994 the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), a group of software engineering researchers, published an influential book — Design Patterns: Elements of Reusable Object-Oriented Software — which still lives on the bookshelves of many a software engineer (which is saying a lot for a book that is more than two decades old!).

Gang of Four at OOPSLA conference, 1994

To this day, the book is widely regarded as an important source for object-oriented design theory and practice. Object Oriented Programming (OOP for short) is a programming model organized around objects. It focuses on the operations those objects can perform, and the data on which those objects operate.

The key idea of a software design pattern, like an architectural design pattern, is that it is a general reusable solution to a commonly recurring problem. It’s not a finished design that can be directly translated into code, but rather it’s a description of how to solve a problem that can be used in many different situations.

A few examples of common software design patterns are:

  • Observer pattern: A tells B to notify A whenever B changes. An example of the Observer Pattern applied to daily life is when you sign up for text alerts for your upcoming flight. If the flight is delayed or if there’s a gate change you receive notification of that change.
Flight alerts keep you informed, like the Observer Pattern
  • Proxy pattern: A is a lightweight stand-in for a big, heavy, inflexible object B. An analogy of the Proxy Pattern in real life is being able to drop a letter into a USPS mailbox on the corner rather than having to make the trek to the nearest post office to drop off your letter. The mailbox is a proxy for the post office.
A USPS box is a proxy for the Post Office
  • Command pattern: treat a series of actions as a single command, which can easily be undone or redone. Real-world examples of this are undo/redo in programs like Google Docs, or the history palette in Photoshop.

Software design patterns are generally language agnostic, meaning they can work equally well whether written in C++, Go, Javascript, Python, Java, Ruby, PHP, Dart, or some other language. They simply outline an approach to solving a problem that many others before you have experienced. The same way they say there are only 7 basic plots to Hollywood movies, there are a finite number of challenges we typically face in software engineering. In the movies, the characters may be different, but the stories they tell are familiar. Similarly in software engineering, the specifics may be different, but there’s a limited number of truly unique problems.

In the software industry, it took many years and legions of people before today’s software design patterns were codified. It was a process of experimentation, refinement, and critique that has helped shape how software designs are conceived and implemented. What’s important, though, is that these patterns were codified, so that the entire industry could benefit.

The same cannot be said for architecture. While Christopher Alexander put forth an initial collection of design patterns, the experimentation, critique, refinement, and eventual adoption that software design patterns have gone through simply hasn’t happened in architecture. The vast majority of building design projects today are bespoke, with people solving the same problems over and over again. At Flux we ask, what might the world look like if the AEC industry were to embrace the notion of design patterns in the same way as the software industry? Could we harness the collective wisdom and knowledge of the AEC community to benefit the entire industry?

What might that world look like?

— Jen Carlile, Co-founder, Software Engineer,

Read Part Two: The Flux Patterns if you’re interested in Flux’s ideas on this topic!