Reconsidering the relevance of design patterns

Users of various programming languages that rose to popularity around or after 2005 like to heap scorn on Design Patterns. The poster children for this scorn are the patterns from the titular book.

One argument against patterns is that a sufficiently expressive language allows these patterns to be implement as libraries. For example, in his paper Design Patterns as Higher-Order Datatype-Generic Programs Jeremy Gibbons opens by saying:

Design patterns are reusable abstractions in object-oriented software. However, using current mainstream programming languages, these elements can only be expressed extra-linguistically: as prose, pictures, and prototypes. We believe that this is not inherent in the patterns themselves, but evidence of a lack of expressivity in the languages of today…

The paper shows how many of the Gang of Four patterns can be implemented in Haskell. Indeed Haskell, and functional languages in general, are capable of expressing abstractions that C++ or Java struggle with¹. I don't think any sane developer would argue that an extra-linguistic solution is superior to a linguistic one.

The question then is, is it possible to have a language that is suitably expressive that all patterns can be described linguistically? My answer is no. To explain why, I want to look at what a pattern is. The Design Patterns book (pg 3) lists four essential elements:

Pattern name
Problem
Solution
Consequences

Of these I think Problem and Consequences are the most important. The problem describes a situation with no clear solution that cleanly addresses it. Consequences describes the pros and cons of the solution. To rephrase: a pattern codifies the tradeoffs involved with solving a common problem. This allows a developer encountering the situation to quickly survey an exemplar solution and consider its repercussions within the program being written.

It is the inherent tradeoff in the solution that, in my opinion, makes a pattern difficult to implement as a library. Since tradeoffs exist at all levels of a software system, I argue that the notion of a design pattern still holds value. Ideally as time progresses and our languages become more sophisticated, the level of abstraction our pattern catalogs discuss should increase.

The false dichotomy in the pattern religion vs patterns are worthless argument undermines us as communities of developers.

A slightly cheeky subtitle of Design Patterns might be “This was easy in Smalltalk, but we have to write C++”