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.
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.
Let me distinguish between fine-grained and high-level documentation of software.
Honestly, I’m no fan of fine-grained source code documentation like the following:
On the contrary, your code should be expressive and read like prose:
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.
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
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 “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.
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, 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, Kris Kafka, 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, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, 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, and Bhavith C Achar.
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|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ – The Core Language
- C++ – The Standard Library
- C++ – Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,