The Design Patterns book came out in 1994. That is twenty eight years ago. In software time, that is several geological eras. Languages died and were born, the web happened, mobile happened, the cloud happened. And yet, last week at work, the fastest moment in a design discussion was when someone said “this is just an adapter” and ten minutes of explanation became unnecessary. The old book is still paying the bills. I want to talk about why.
A quick history
In 1994 four authors, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, published Design Patterns, Elements of Reusable Object Oriented Software. People call them the Gang of Four, or GoF. The book catalogued twenty three patterns, which are recurring solutions to recurring design problems, each one with a name, a context, and the trade offs.
Erich Gamma alone would be worth listening to even without the book. He later co-created JUnit with Kent Beck and worked on the tools many of us use every day. These were not academics inventing problems. They were practitioners naming things that working programmers kept rediscovering.
And the naming is the point. People remember the book as a catalog of class diagrams. I think the diagrams were the least important part.
The real product was vocabulary
Here is my honest opinion after years of using this stuff. Some patterns aged badly. Some exist only because the languages of the 90s were missing features that modern languages have built in. If you write a Visitor in 2022 in a language with pattern matching, you might be doing extra work for nothing. The catalog is dated in places, and that is fine, catalogs age.
But the book gave us something that did not age at all. A shared vocabulary. A set of words that compress big design ideas into a single term that two professionals can exchange in one second.
Think about what actually happens when a developer says “this class is an adapter”. In one word, the listener knows the class wraps something with an inconvenient interface, exposes a convenient one, holds no business logic of its own, and can be safely ignored when reading the domain rules. That is a paragraph of information delivered in one word, with both sides confident they mean the same thing. Factory, observer, decorator, strategy, facade. Each one is a small compression algorithm for design conversations.
Martin Fowler has spent his career on this kind of naming work, his Catalog of Patterns of Enterprise Application Architecture is basically a dictionary of patterns for enterprise software, and he makes the same point. A pattern name is a reference into shared knowledge. The value is in the reference, not in any specific implementation.
Vocabulary is money
Now let me put on my business hat, because my thoughts as a developer always involve cost for the company and value for the client, and vocabulary is one of the most underrated ways a team saves both.
Onboarding. A new developer joins the team and opens an unfamiliar codebase. If the code says PaymentGatewayAdapter and FraudCheckStrategy and the names are honest, the new person navigates by concepts they already know from any previous job. They become productive in days. Without shared vocabulary, every codebase is a foreign city without street signs, and the new person needs a senior guiding them around for weeks. Senior time is the most expensive time on the team. A new dev understanding “this is an adapter” in seconds, instead of in a thirty minute meeting, is money saved, and it is saved again with every new person, forever.
Miscommunication. Most expensive bugs I have seen were not coding mistakes. They were two people agreeing in a meeting while imagining different things, and discovering it three weeks later in production. Shared pattern names shrink that gap. When the words are precise, the disagreement surfaces in the meeting, where it costs nothing, instead of in production, where it costs everything. English is my second language, so maybe I notice this more than most people. Precise shared words are not a luxury. They are how teams avoid building the wrong thing politely.
Code review speed. A reviewer who can write “consider a strategy here instead of this switch” gives a complete suggestion in one line. The author either knows the term or can look it up in a book that has existed since 1994. Compare that with explaining the whole idea from zero in every review.
The trap, because there is always a trap
I have to say this part, because the patterns book has also destroyed codebases. In the 2000s there was a fashion of using patterns to show seniority. AbstractSingletonProxyFactoryBean is a real name from a real popular framework. I will not say which one, but it rhymes with Spring . I worked with systems where finding the actual business logic was an archaeology project under five layers of pattern ceremony.
Patterns are vocabulary, and good writers do not use every word they know in every sentence. The skill is not knowing the patterns. The skill is knowing when the problem in front of you is actually the problem the pattern solves, and saying it in the simplest words that work. A pattern applied without its problem is pure cost, more indirection, more files, more onboarding time, the exact opposite of the value we wanted.
Old does not mean dead
So why does a 1994 book still pay the bills in 2022? Because it was never really a book about object oriented class design. It was a book that gave our profession a piece of shared language, and language does not depreciate like technology does. The frameworks I used in 2002 are museum pieces. The word “adapter” works exactly as well today as it did then, and it will work in 2040.
Pax et bonum.