The Advantages of Patterns

Before I write about patterns in my upcoming posts, I have to answer one question first. What are the advantages of patterns? As you may assume, I see many advantages, but I boil them down to three points: well-defined terminology, improved documentation, and learning from the best.

I gave my first talks about design patterns. This was around 2002 – 2008. Why? Patterns are probably the most valuable and impactful abstraction in modern software development.

Now, let me write about the important stuff.

Advantages of Patterns

My argumentation is based on three facts: well-defined terminology, improved documentation and learning from the best.

Well-defined terminology

Patterns establish a well-defined terminology. Imagine, I go for a run and I explain to you that I saw an asthoning animal. I explain it to you in my bad English. The animal had kind of the size of a cat and had fur and long ears. Its hind legs were extremely long. It could, therefore, jump three meters far and two meters high. While running, it could its direction quickly. You may guess which animal I saw: a European hare. Using the exact term helps a lot. Now you have the term and you can look it up on Wikipedia. This is for me the main benefit of patterns. We have well defined-terminology. We know, what we are talking about.

Let’s make it more concrete. You want to implement a newsreader and ask me for my advice. The customer of your newsreaders should be automatically informed if some news happens. My answer can very verbose and explain that your newsreader should have a register and unregister functionality. Additionally, the newsreader stores all the customers and each customer should support a notify member function. When the newsreader publishes something, it goes through its list of customers and calls and notifies all of them. There is more to it. The newsreader could send the news, or only send that there is news in which the customer could be interested. I’m not done with my advice, but I stop here. In contrast, my answer could be one term: the observer pattern. You can read the details in the literature.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

Improved documentation

Let me distinguish between fine-grained and high-level documentation of software.

Fine-grained documentation

Honestly, I’m no fan of fine-grained source code documentation like the following:

// initialize a vector of strings
std::vector<std::string> myStrVec = {"12345", "123456", "1234", "1", "12", "123", "12345"};

// sort the vector of strings based on their length ascending
std::sort(myStrVec.begin(), myStrVec.end(), lessLength);

On the contrary, your code should be expressive and read like prose:

std::vector<std::string> myStrVec = {"12345", "123456", "1234", "1", "12", "123", "12345"};

std::sort(myStrVec.begin(), myStrVec.end(), [](const std::string& f, const std::string& s){return f.length() < s.length();});

The code tells the truth and is by definition always up to date.

It happened so often in my career as a software developer that I should maintain legacy software and improve it. Typically, this software was very complex, and it took me a considerable amount of brain power to understand it. Sometimes I couldn’t even understand the software. You may guess, how happy I was that I found documentation in the source code that helped me to put the puzzle pieces together. Sadly, I recognized later, that the documentation was out of date and I invested my brain power in the wrong direction. I went back to square one. Fine-grained source code documentation becomes easily out of date. Out-of-date documentation is awful. Your code should be self-explanatory.

High-level documentation

Honestly, I’m a big fan of high-level documentation of software.

For example, you provide a graphic in UML or SysML describing the architecture of the software and say, that you apply the reactor pattern in your software. The reactor pattern is an architectural pattern. It describes a proven solution to build event-driven applications that can accept multiple client requests simultaneously and distribute them to different service providers. Now, that I get the big picture, I can dive more into the details:

Study the literature about the reactor pattern
Discuss its impact with my colleagues
Identify the critical components of the reactor pattern in the software; There must be components such as a reactor, an event demultiplexer, events, and various event handlers to be part of the software. They use names like handleEvents, registerHandler, removeHandler, select, or getHandle.

Furthermore, to implement the various aspects of a reactor pattern, design patterns come to our rescue. For example, the event handler should be informed if a special event happens. An observer pattern may here be the right choice. Additionally, you should document that you used the observer pattern to solve the challenge. This is very valuable high-level documentation.

Learning from the best

Patterns are just learning from the best. You pick the brain of Kent Beck, James Coplien, Grady Booch, or Eric Gamma, to name a few.

Patterns are “code reuse” on a high level. This is the kind of “code reuse” that worked best. A pattern describes a typical challenge in a specific context and its proven solution. A pattern also answers the following questions:

When should you not use the pattern?
Which patterns are and can be considered instead?
Where is the pattern used?
Which variations of the pattern exist?

Just imagine, how nice it would be if you design new software, and you don’t fall into each pitfall.

What’s Next?

Most software developers assume that the terms patterns and design patterns are interchangeable. This is, of course, wrong. Patterns is a broader term and include design patterns. My historical detour and first classification of patterns in my next post should make my point.

Post Views: 3,572

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS