Chapter 9 Design Patterns and Idioms

Some people believe that Gamma et al. had invented all the design patterns that are described in their book. But that’s not true. Design patterns are not invented by

someone, they are usually discovered. The authors have examined software systems that were well made regarding certain qualities, especially flexibility, maintainability, and extendibility. They found the cause of these positive characteristics in the code base and described them in a canonical form.

After the book of the Gang of Four was published, it was thought that many other authors would join the bandwagon and there would be a flood of pattern books in the following years. But this did not happen. Indeed, in the following years there were a few other important books on the subject pattern, such as Pattern-Oriented Software

Architecture (also known under the acronym “POSA”) [Busch96] or Patterns of Enterprise Application Architecture [Fowler02], both about architectural patterns, but the expected huge mass stayed out. But from time to time a few new patterns appear, especially in the light of new trends in software development. In recent years, for example, special patterns have become known for the environment of highly distributed, highly available and hyperscaling software systems, which are often based on so-called microservice architectures. One example is the Circuit Breaker [Nygard18], a fault-tolerance pattern that can handle the problem that remote requests to other systems or processes can either fail or take too long.

Design Principles vs Design Patterns

In the previous chapters, we discussed a lot of design principles. But how are these principles related to design patterns? What is more important?

Well, let’s assume just hypothetically that perhaps one day object-orientation will become totally unpopular, and functional programming (see Chapter 7) will be the dominating programming paradigm. Do principles like KISS, DRY, YAGNI, single

responsibility principle, open-closed principle, information hiding, etc., become invalid and thus worthless? The clear answer is no!

A principle is a fundamental “truth” or “law” that serves as the foundation for decisions. Therefore, a principle is in most cases independent of a certain programming paradigm or technology. The KISS principle (see Chapter 3), for instance, is a very universal principle. No matter if you are programming in an object-oriented or a functional style, or using different languages like C++, C#, Java, or Erlang: trying to do something as simple as possible is always a worthwhile attitude!

376