Language
If you look at any modern and reasonably sized piece of software, you will
surely come across something with the word factory in the name. You might also
find a few singletons in the code. The larger the codebase, the more likely it
is that you will see recognisable object-oriented design patterns. You may
even note a query_decorator, a list_iterator, a status_observer, and possibly
even a page_builder or two. These pattern names have become thoroughly
entrenched in our software development language.
Though not as widely studied these days, design patterns are regularly used by people who have yet to see a copy of the GoF book[GoF94]. The names of these patterns are baked into tutorials, how-to guides, and example code, all of which people copy and paste into their projects.
Design patterns first appeared in
However, there is a downside to the language-like qualities of patterns; they become less useful in the long run. The benefits of structure and communicability also have their pitfalls, as they lead to a loss of essence when referred to by an arbitrary handle.
As an example of the weakness of words, what does the word ‘literally’ mean to people now? In the past, it used to mean ‘real’ and ‘actual’, not the imprecise term it has now become. Additionally, what does ‘done’ mean to the people you work with on different projects? Language evolves. Sarcasm aside, words and their meanings are relative to the environment and the participants in that environment. We need to recognise that definitions are not eternal and immobile—but rather cultural and flexible.
The GoF Visitor.
The books published in the 1990s were full of recognised patterns—and
pattern authors gave names to each of them. The names stuck around, but our
understanding of what those patterns mean has drifted. When we copy patterns
without completely understanding them, their meaning mutates. If we copy a
visitor pattern from an implementation that walks a structure of composite
objects, but we fail to see the details of the typed callbacks, the pattern word
will now mean something else.
We can be forgiven this as even the GoF referred to the
A Walking Pattern.
Beyond the individual names of patterns, nowadays we regularly exchange the term design pattern with technique or UX design-systems. Some authors will add ‘design patterns’ to the title of a book or webpage to instil a sense of validity to the content delivered. It is intensely dissatisfying to observe how anything that indicates a property will inevitably be mimicked and ruined; from black-and-yellow striped but non-threatening insects to five-star review bots. However, why is this dilution of meaning not seen as a problem by those involved in the patterns movement? Worse still, when it is recognised as a problem, why is it seen as somehow unavoidable?
Aside from co-opting the term, UX design patterns exhibit another problem. Even though some people complain that the GoF patterns are idiomatic, UX patterns suffer from the same flaw to a much greater extent. I explain in more detail later what idiomatic means for patterns, but compared to authentic pattern forms, idioms are less powerful, less adaptable, and often unfalsifiable.
Indeed, UX patterns don’t fit into the original definition by Christopher Alexander, but does this matter? Are idioms just as useful in practice? Given how the usage of the term has changed, what is the value in trying to fix anything about design patterns if they don’t exist anymore, except in the form of a book and some recurring names?
I will answer these questions and explore how to regain some of the benefits of patterns without requiring the whole system to be overhauled.
Naming is hard. ‘Our names for the patterns have changed a little along the way. “Wrapper” became “Decorator,” “Glue” became “Facade,” “Solitaire” became “Singleton,” and “Walker” became “Visitor.”’[GoF94] p. 353. We shall see later how Christopher Alexander approached this problem through the use of diagrams.