Afterwood

Afterwood

By Chris Oldwood

Overload, 28(160):20, December 2020


Design Patterns emerged last century. Chris Oldwood explains why he thinks they are still relevant.

A perennial question that crops up fairly regularly on social media questions the value of design patterns. The clickbait-styled affairs declare that design patterns and the similarly titled Gang of Four (GoF) book have little relevance in today’s programming toolbox and should simply be ignored as an anachronism. The more curious programmer that seeks more substance may struggle to see past a movement which superficially appears to have seen better days.

And who can blame them? If you’re a fresh-faced programmer who comes across a book from 1994 with example C++ code that passes around raw pointers coupled with 90’s style UML class diagrams of inheritance hierarchies, wouldn’t you be somewhat concerned? The nail in the coffin would probably be the number of patterns in the seminal GoF book which evaporate once you consider C++ has supported lambda functions for almost a decade now – functors are so last Millennium! Even the Double-Checked Lock, should one be inclined to touch the pariah that is Singleton, finally works by design.

Java, which didn’t exist at the time the book was written but was still hugely popular during the rise of the movement, has even sprouted lambda functions to remove the burden of a few recurring problems the book addressed. While on the subject of Java, some of the aversion to design patterns must lie with that unfortunate practice of naming classes by chaining together the names of design patterns, as if trying to win at ‘Design Pattern Bingo’. I have personally been the recipient of code which contained the monstrosity:

  public class UnitOfWorkXxxServiceFacadeDecorator

(In this instance, the entire class hierarchy was replaced by a couple of succinctly named C# extension methods that wrapped a caller-provided closure.)

So, are they right then? Are design patterns a waste of time – a solution to a problem in a context where that context was the early ’90s and the problem was simply poorly designed programming languages?

No, I don’t think so. The Gang of Four legacy is not some old-fashioned C++ code and a bunch of UML diagrams with large class hierarchies; it’s the ubiquitous language they created. The value was never in how they realized the solution in code but in the vocabulary they chose for describing the recurring problem they identified. By distilling the essence into just a single word (or three), they have given us the power to communicate complex ideas easily. Imagine how much longer a design meeting would take if you had to keep saying ‘a one-to-many relationship between objects so that when one object changes all its dependants are notified and updated automatically’ instead of simply saying ‘observer’?

Even if some design patterns use terms that already had a fairly established meaning, such as Proxy (GoF), Cache (POSA3), and Pool (POSA3), the community has taken those ideas and given them a more usable definition. Instead of leaving them to remain ambiguous, they have given them clarity. As Dijkstra once said:

The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

Each pattern does not exist in a vacuum. Together, it and other related patterns form their own language that allows people to explore design options in a specific problem space without getting dragged into the implementation minutiae too soon. Once the foundation patterns in the original GoF text and its ilk, such as the first volume of the Pattern Oriented Software Architecture (POSA) series, had arrived further catalogues appeared that focused on particular topics such as resource management, concurrency, integration, etc. Both the POSA and Pattern Languages of Program Design (PLoPD) series stretched to 5 volumes and the annual PLoP conference continues today despite starting back in 1994. To paraphrase Mark Twain: any rumours of the patterns community’s demise are greatly exaggerated.

Many of those early patterns are still relevant to today’s design discussions because the vocabulary is still with us. The aforementioned ‘observer’ might have matured over the years and more closely resembles its sibling – Multicast, introduced in the follow-up book Pattern Hatching – but it’s still there at the heart of any event driven system. The terms Adapter, Facade, Factory, and Proxy had a life before the GoF and naturally continue to live on, albeit with a more refined definition. Iterators are a fundamental part of C++, Java, and C#, and Decorators became a key idiom in Python. Decorators in Python are considered far less rigid than the GoF definition, more akin to Aspect Oriented Programming, but that might be because the AOP term post-dates the Decorator pattern; either way, there are big similarities in the metaphor, and that aids communication. One pattern that definitely seems to have gained in popularity over the years is Builder (coupled with fluent interfaces), no doubt due to the rise of automated testing where non-trivial object graphs created in tests need the salient details to remain prominent

Patterns aside, the GoF book still has plenty to say. Section 1.6 alone contains a useful summary of many of the core ideas behind object-orientation including what is probably one of the most significant programming axioms – program to an interface, not an implementation

The Conclusion chapter in Design Patterns starts by saying “It’s possible to argue this book hasn’t accomplished much.” I think it’s fair to say that 25 years later you would be hard pushed to agree with this statement. While the example code is dated and the ubiquity of closures in modern programming languages have consigned some of the solutions to the history books, the vocabulary appears to be timeless. Their concise lexicon is the real legacy of the Gang of Four, and I for one thank them for helping me spend less time in meetings and having more productive design conversations.

Chris Oldwood is a freelance programmer who started out as a bedroom coder in the 80s writing assembler on 8-bit micros. These days it’s enterprise grade technology from plush corporate offices the lounge below his bedroom. With no Godmanchester duck race to commentate on this year, he’s been even more easily distracted by messages.






Your Privacy

By clicking "Accept Non-Essential Cookies" you agree ACCU can store non-essential cookies on your device and disclose information in accordance with our Privacy Policy and Cookie Policy.

Current Setting: Non-Essential Cookies REJECTED


By clicking "Include Third Party Content" you agree ACCU can forward your IP address to third-party sites (such as YouTube) to enhance the information presented on this site, and that third-party sites may store cookies on your device.

Current Setting: Third Party Content EXCLUDED



Settings can be changed at any time from the Cookie Policy page.