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!).
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.
- 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.
- 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.
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, Flux.io
Read Part Two: The Flux Patterns if you’re interested in Flux’s ideas on this topic!