The Big Wheel Keeps on Turning
Design patterns have been around for a long time
The Gang of Four (GoF) popularized software design patterns, in their book Design Patterns, but they didn’t originate the concept. Design patterns have their formal roots in the world of architecture from Christopher Alexender, et al. in the four-volume set: A Pattern Language: Towns, Buildings, Construction published in 1977:
The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
I think that patterns have been around a lot longer than that, even for millennia. I consider the Wheel a design pattern in the mechanical domain. There is no one wheel that works in all scenarios. There are many types of wheels such as: pottery wheels, water wheels, wagon wheels, hamster wheels, Ferris wheels, and even wheels we no longer call wheels, such as pulleys and gears.
In each case, the designer has the design concept of a wheel with an axle at his or her disposal to solve a problem. The wheel drives the axle, or the axle drives the wheel. But this is only a starting point. Each wheel must be designed appropriately for the context of each individual use case.
The wheel feels obvious to us since it’s so ubiquitous, but it took centuries if not millennia to perfect. Pre-Columbian indigenous peoples in the Americas, even with their own sophisticated technology, never developed it.
In 1995 the GoF brought design patterns into the software world when they cataloged software design patterns in their book. This catalog consisted of patterns that were presented at conferences during that time. Software Design Patterns History provides a summary of others who were defining software design patterns at about the same time. The GoF design patterns fall mostly within the paradigm of Object-Oriented languages, but design patterns are not limited to just Object-Oriented paradigms. Software Design Patterns Classification and List summarizes the GoF patterns plus some not cataloged by the GoF.
The GoF defined a set of attributes to describe each design pattern such as name, intent, structure, code samples, etc. More attribute details can be found in Software Design Pattern Documentation. While not necessarily GoF attributes, here are some design pattern attributes that I find most beneficial:
- Nomenclature – Giving a pattern a name allows developers to discuss a design concept using a shared ubiquitous language, which facilitates communication. Data structures provide an example of this efficiency.
Image how long it would take one developer to describe a doubly linked circular list if we didn’t already have a name for it. - Chunking – Design patterns become a single design chunk even if comprised of other software elements. I can only hold about seven ideas (or chunks) at any given time in my short-term memory. A named/chunked design pattern occupies only one memory slot. If it were not for this chunkability, the individual elements of the design would each occupy one of those memory slots.
- Flexibility – The design patterns have no domain other than their paradigm. They can be applied in almost any application. And each design pattern use can be designed for a specific use, much like how each wheel can be designed for its specific use.
- Field Tested – Design patterns are not endorsed until they’ve been used in several different projects. When you use a design pattern, you have the confidence that you’re not the first person trying some crazy design idea.
- Less Head Scratching – Though design patterns are very flexible, they are also based upon well-defined structures that encourage a modular design and separation of concerns. I know this sounds cliché, but once I’m satisfied with a design, my code often writes itself and it tends to just work. Difficult or stubborn bugs decreased significantly for me once I started to incorporate design patterns.
The design pattern properties I listed above apply to data structures and algorithms as well. So why aren’t design patterns considered data structures or algorithms?
I think the distinction goes back to being a software cook verses being a software chef. Data structures and algorithms are like recipes that all software cooks can follow. Design patterns are like culinary techniques that only the skilled software chef knows how to apply.
