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.

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

man 5649929 1280

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.


Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, Marko, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, Louis St-Amour, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Neil Wang, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Evangelos Denaxas, 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, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, and Wolfgang Fütterer.


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



My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small


My special thanks to PVS-Studio PVC Logo



I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

Bookable (Online)


Standard Seminars (English/German)

Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.


Contact Me

Modernes C++,





English Books

Course: Modern C++ Concurrency in Practice

Course: C++ Standard Library including C++14 & C++17

Course: Embedded Programming with Modern C++

Course: Generic Programming (Templates)

Course: C++ Fundamentals for Professionals

Interactive Course: The All-in-One Guide to C++20

Subscribe to the newsletter (+ pdf bundle)

Blog archive

Source Code


Today 581

Yesterday 4232

Week 581

Month 11510

All 10354817

Currently are 116 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments