Chapter 9 Design Patterns and Idioms

In contrast, a design pattern is a solution for a concrete design problem in a certain context. Especially those ones that are described in the famous Design Pattern book

of the Gang of Four are closely related to object-orientation. Therefore, principles are more long-lasting and more important. You can find a design pattern for a certain programming problem by yourself, if you have internalized all the valuable principles.

“Decisions and patterns give people solutions; principles help them design their own.”

—Eoin Woods in a keynote on the Joint Working IEEE/IFIP Conference on Software Architecture 2009 (WICSA2009)

Some Patterns and When to Use Them

As mentioned, besides the 23 design patterns described in the Gang of Four book, there are of course more patterns. Even nowadays, new patterns appear from time to time. Particularly in the context of highly distributed and concurrent systems, specific patterns of resilience, consistency ensurance, and fault tolerance have emerged in recent years. Some patterns are often being found in many code bases, while others are more or less rare or exotic.

The following sections discuss some of the in my opinion most important design patterns.

By the way, we used a few design patterns in the previous chapters, some even relatively intense, but I did not mentioned it. Just a slight hint: In the book of the Gang of Four [Gamma95], you can find a design pattern that is called… Iterator!

Before we continue with the discussion of individual design patterns, a warning must be pointed out here.

Warning  Don’t overuse design patterns! No doubt, design patterns are cool and sometimes even fascinating. But an overplayed use of them, especially if there are no good reasons to justify it, can have catastrophic consequences. Your software design will suffer from useless overengineering. Always remember KISS and YAGNI (see Chapter 3).

Let’s take a look at a few patterns.

377