Chapter. Defining design patterns
I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it,
— US Supreme Court Justice Potter Stewart defining design patterns in Jacobellis v. Ohio
He was actually describing pornography, but on the internet is that anything really that different from porn? Hopefully, by the end of this, I’ll convince you that there really is no difference between design patterns and pornography.
Design patterns were first brought to the programming world by the book Design Patterns: Elements of Reusable Object-Oriented Software, but commonly called the Gang of Four book, because it had four authors and was referenced a lot.
In it, it defines design patterns by quoting a definition verbatim from its inspiration in Christopher Alexander’s works on patterns:
Each pattern describes a problem which 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.
— Christopher Alexander, The Timeless Way of Building
Since Christopher Alexander is referring to building real buildings and towns, not software, the definition confuses.
Since I posited that design patterns are like pr0n, it is impossible to define a design pattern directly. We can, however, speak to properties that all design patterns, whether they be in building architecture or programming, seem to have and have been alluded to in the above definition. They are:
- Patterns are a vocabulary (because they have a name)
- Patterns are a solution to a problem (“a problem… and core of the solution to that problem”)
- Patterns are a component of a whole (“occurs… in our environment”)
- The right pattern to use depends on context. (there are multiple “core solutions” to the same problem)
- Patterns are implementation independent (“you can use this solution a million times over, without ever doing it the same way twice”)
- Most importantly, patterns have consequences (if there were only one best pattern to use, there wouldn’t be a need for a vocabulary to distinguish among particular problem/solutions)
Let’s try to understand this by looking at design patterns outside of coding programs and in web page design:
A (web design) pattern (web (design pattern)? web design design pattern?) that we can all agree exists happens when we talk about “breadcrumb navigation” in the original Yahoo! directory:
When I said the “breadcrumb navigation”, you probably knew exactly what I meant without needing the above image to tell you. So the first property of of a particular design pattern is it is vocabulary—I am using the term, “breadcrumb navigation”, to communicate to you something (the web design pattern above).
This pattern is clearly doing something—it is helping us navigate this deeply nested hierarchy by showing where we are (in this case, the “PHP” part of the directory. That means this pattern is solving a problem—one of navigation.
But look at the “tabbed navigation” popularized by Amazon.com:
Different vocabulary, different design pattern, same problem (the problem of navigation)! In both cases, the patterns are a a component providing the navigation for and location in of the web page in the whole web site. In the former, the page is the PHP part of the directory; In the latter, the page is the welcome page of Amazon.com, and its design compromises part of the whole.
Furthermore, which one we choose (bread crumbs or tabs?) is based on the context: if we want to show location in a deeply nested hierarchy, we use a bread crumb; if we want to emphasize which top level area we are in, we highlight the tab.
Now look at Apple’s site that same year:
These are clearly different specific tabs, but the same pattern (use “a million times over, without general doing it the same way twice”). In fact, I haven’t needed to tell you the specific HTML, CSS, Javascript, or server-side code needed to implement the pattern because it is not tied to those particulars! Hence, it is implementation independent.
Why didn’t Apple use breadcrumb navigation? Because they sell a limited number of clearly delineated product lines, and tabs emphasize this. The consequence in navigational design is always an efficient use of space to delineate position and importance. If Apple wanted to show every product they’ve ever made including Apple ][, Mac, iPod, iPhone, iPad, TV, Music, and Watch space, they might have used breadcrumbs instead. In fact, EveryMac.com uses modified breadcrumbs to do just this!
When business needs change, as is the case of Amazon moving from Books only to Books, Music, and Movies to nearly any product they can possibly sell, the limited space of a Tab navigation started to be come archaic and burdensome. So, they switched to turning the tab into a vestigial design element before eliminating it altogether by replacing it with a “Drop down menu” and moving the “Search box” to occupy its prominent position — two different navigational web design patterns.
That is Amazon running into the consequences of its original choice and paying that back down over years.
When we apply this to programming design patterns, all we can say is if it satisfies the above qualities and is in programming, then it’s probably a programming design pattern.
That may not sound like much but it actually tells us a lot.
Algorithms are not patterns.
Best practices are not patterns
“I know it when I see it.” is a colloquialism used when categorizing something where the category itself is subjective or lacks a clear definition of parameters.
No less an authority than Martin Fowler, who introduced design patterns to web development said:
There’s no generally accepted definition of a pattern…
— Martin Fowler, Patterns of Enterprise Application Architecture
Isn’t “I know it when I see it” just the case with a design pattern? After all, in this chapter alone, we have seen it’s used in architecutre of buildings (Christopher Alexander’s Timeless Way of Building), in the design of cities and towns (Christopher Alexander’s next book), in object-oriented programming (Gang of Four book), in web page design (my analogy), and in enterprise web development (Martin Fowler above).
Indeed, other than the criteria presented above, the nature of a design patterns defies “direct definition” because its meaning is determined by context in the same way the meaning of what is “pornography” depends on the social values of the time.
Justice Potter Stewart is the OG design pattern guru.