In the Mood for Programming

Design Patterns in the Wild: Introduction

I remember my first more in-depth encounter with design patterns was when I was preparing for interviews for my first programming job. My sources were either Gang Of Four’s Design Patterns (GoF), Head First Design Patterns (HDFP), or some internet tutorials and Youtube videos. Rummaging through these sources left me quite perplexed. The examples used were either quite arcane or laughingly trivial. I either had to grapple with some obtuse GUI terminology or just leaf through some examples that concerned baking pizza or elephants being turned into ducks. In both cases, I was left without any intuition about how real-life systems might take advantage of these design patterns. Fortunately, during junior interviews, you are mostly asked to enumerate and simply describe a selection of design patterns, therefore, you never need to thoroughly understand the logic and the places when it might be appropriate to use the pattern. So, as a junior engineer, you might very soon forget them and think that they are some useless academic exercise or historical programming artifacts of some long-forgotten languages. Or that is at least how I felt.

However, after working with real-life production systems for a few years now, I kinda started changing my perspective. Once in a while, I glimpsed some strangely familiar prefix or suffix, or just a documentation comment that indicated that what I might be looking at, is a design pattern. It happened when checking documentation for a library dealing with binary serialization, or writing code for signing public certificates, or just during the browsing of the source code of one networking library. I have been given the opportunity to spot design patterns in their natural habitat.

And so I thought to myself, that I might try to gather these few references I have been able to witness and write about them. Show that there are really amazing usages of design patterns in modern codebases and that it is very useful to know some of them. I personally have been able to learn a lot thanks to looking at these pieces of code, and have already applied a few of those gems (I hope successfully).

Each article of the series will try to present one design pattern, and then I will move to show some actual components of an open-source project where the pattern is applied. Sometimes, I might take a detour to introduce the project itself because the component might be quite entrenched in the internal logic of the library and therefore in order to understand it, it might be necessary to also get a feeling of a broader architecture. Most of the examples I am using are from projects implemented in Golang, Python, and C++, as I have direct daily contact with these languages. I imagine there might be some pretty good examples of design patterns in C# and Java (I have been able to find this list of design patterns used inside Java core libraries: https://stackoverflow.com/questions/1673841/examples-of-gof-design-patterns-in-javas-core-libraries), but, unfortunately, I haven’t had that much of a contact with libraries of these languages. I also would like to stress that some of the design patterns I will be describing might not correspond one-to-one with the UML diagrams, descriptions, or examples in the GoF or HFDP books. However, my decision to incorporate them was oftentimes based on some significant similarity in the context of usage or the similarity of the purpose.

Just a final request. If you would like to share some information about a design pattern (one of those described in the GoF or HFDP) you found in some active open-source project, I would be thrilled to hear about it. It doesn’t need to be in Golang, Python, or C++. If it is in Java or C#, it’s even better, as it will force me to look closely into their codebases! And even if you don’t know of any usage of a real-world design pattern, but you would like to share some other piece of advice or a comment, don’t hesitate to write to me!