[Programming, Opinion] Should you read the GoF(design pattern) book?

image source: https://www.irasutoya.com/2021/01/blog-post_11.html
(A sleeping woman in front of a PC)

TL; DR

• I won’t recommend reading it without much experience in programming - Have experience of real-world problems first
• Use it as a reference, especially when building a complex system on your own

Introduction

In software engineering world, there are several books that allegedly called MUST-READ. There are millions of such, but one of the noticeable books is the "Design Patterns" book a.k.a. the GoF(Gang of Four) book. Regardless of its age, this book is being mentioned frequently on the Internet even in 2024 as of this writing. To introduce it shortly, it is considered as a "bible" for designing objected-oriented applications, with examples in C++ and SmallTalk. Some even say you MUST READ it before becoming a senior level engineer.

Attracted by so many compliments on this book, I read through this book as well, checking every pattern introduced. But after finishing the book and working on a real-world product, I now doubt about whether this book is really something you MUST READ. Has this book helped me writing better code, or led to making better design and decision in software development in general?

DISCLAIMER: I am not a senior engineer with 10+ YOE, so my opinion is highly skewed towards the standpoint of junior software engineers of YOE less than 5 years. I highly value different opinions on this book as well.

Why I won’t recommend the GoF book for beginners

One thing I want to speak up is that this book is not for beginners in programming and software engineering. There are several reasons I can think up but here are two main things:

1. You might focus too much on the patterns themselves

You may have heard these seemingly "professional" jargons from a lot of documentations, such as Singleton, Facade, Factory, Strategy, etc. These are the patterns introduced in the GoF book. If you don’t have that much experience in software engineering, you may feel that you have to read the book to understand these concepts thoroughly.

However, personally I think this is a bad approach to software engineering in general. Being exposed to the patterns first may obscure the practical intention of the patterns themselves - organize the solution in structured ways to solve designing software problems. Unless you face and touch the problems first, you won’t fully grasp why you use those patterns in the first place.

Conversely, you may concentrate on memorizing the patterns and their code examples. But do you actually understand why the singleton pattern is used here and not there, and why the prototype pattern is not discussed in languages like Python? These insights are only learnable from real experiences, not from the book.

Basically, we only need knowledge that we use. There should be several patterns that are implicitly used in your daily work, but even so, you don’t have to memorize the patterns themselves. If your hands know them, then you know them.

2. The code examples are abstract and you can’t run them

The other reason is because of the code examples introduced in the book. The code itself is not bad, although it is rather old(even before C++11). The problem of the code examples is that it is abstract and not used in a real application example.

Of course, the book introduces a real application example before the catalogs, in chapter 1 and 2. However, in my opinion it is too short to grasp each of the patterns. Also, in 2024, we need examples that we are more familiar with, such as web, mobile, and machine learning applications.

When it comes to the examples in the individual patterns, they are not a part of an actually running application, but a collection of mock classes and functions in C++. Thus, even if you read the code, you won’t really understand how it would be implemented in a real application. And the problem is, you only learn from concrete code that actually runs and gives expected results.

How I would approach this book in the second read

But I am not saying you should not read this book. Rather, I think it would be good to read after having experienced in several software projects so that you can relate your own experience to the patterns from the book. If I would read this book again in the future, I would take the following approaches:

1. Looking up the list of the patterns only when the names of the patterns come up from documentations

Some software authors love to quote the patterns introduced in this book. Therefore, unfortunately, you have to know what the patterns do that the author of a documentation mentions(for example, Rust's THE BOOK directly discuss the state pattern in a single chapter). However, it doesn’t mean that you have to know every single design pattern in GoF. Only after you bump into the jargons, then you look up the book.

Read the general introduction of the pattern from the book, then read the documentation. Compare the code examples in the book with the one in the documentation. Write your own code according to the documentation and understand why the author mentions those specific patterns.

For example, LlamaIndex framework uses the singleton pattern for configuration. Why did the authors use this pattern for configuration, and why not something else? You many find useful insights from the GoF book about this design decision.

2. Consulting the designs when designing a complex system on your own

Sometimes, we may create an application that is totally brand new - not using highly opinionated frameworks written by others but your own one. It is absolutely necessary for you to design the application from scratch, and you need to consider various options.

In this case, I think it would be good to brush up on your knowledge on design patterns. The GoF book already contains a lot of patterns with clear explanations in diagrams, so it is a good way to replenish your options. Especially, the design patterns in the book are for managing a complex system efficiently, thus you would benefit from skimming through the list of the patterns.

Conclusion

Against the hype that “You should read the GoF book”, I strongly claimed here in this article that you should face the real-world problems first and use the book as a helpful reference. There is no such book as MUST READ - you USE books for your own good and efficiency.