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 with1. 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
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++”