Designs Patterns

Table of Contents

What is a design pattern?
#

Design patterns are classic solutions to recurring problems in software design. They are like blueprints or templates that can be customized to solve a recurring problem in our code.

You cannot simply find a pattern and copy it into your program as you would with ready-to-use functions or libraries. A pattern is not a specific piece of code, but rather a general concept for solving a particular problem. You can follow the pattern’s principle and implement a solution that fits your own program.

Patterns are often confused with algorithms, as they both describe classic solutions to known problems. An algorithm always clearly defines a set of actions that will lead you toward a goal, whereas a pattern is a higher-level description of a solution. The code used to implement the same pattern can be completely different when applied to two distinct programs.

An algorithm is a bit like a cooking recipe, its steps are clear and guide you toward a specific goal. A pattern is more like a blueprint: you can see its features and the results obtained, but how to implement it is up to you.

What do you find in a design pattern?
#

Most patterns are presented in a very general way, so they can be reproduced in all contexts. Here are the different sections you will usually find in a pattern’s description:

The pattern’s Intent provides a brief description of the problem and the solution.

The Motivation explains in detail the problem and the solution offered by the pattern.
The Class Structure shows the different parts of the pattern and their relationships.
The Code Example written in one of the most popular programming languages facilitates general understanding of the idea behind the pattern.

History of design patterns
#

Who invented design patterns? The question is legitimate, but the term is poorly chosen. Design patterns are not obscure and sophisticated concepts; quite the opposite. They are classic solutions to known problems in object-oriented design. When an issue keeps recurring in different projects, someone eventually decides to detail the solution and give it a name. This is often how a pattern is discovered.

The concept of design patterns was first described by Christopher Alexander in A Pattern Language: Towns, Buildings, Construction. The book invents a “language” for designing an urban environment. The units of this language are patterns. They can indicate the expected height of windows, the number of floors a building should have, the size of green spaces in a neighborhood, etc.

This idea was adopted by four authors: Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm. In 1994, they published Design Patterns: Elements of Reusable Object-Oriented Software, in which they applied this concept of patterns to programming. The book contains 23 patterns that solve different object-oriented design problems and very quickly became a bestseller. Its name was a bit too long and over time, it was naturally replaced by “the book by the Gang of Four,” then further shortened to “the GoF book.”

Since that day, dozens of new design patterns for object-oriented programming have been discovered. The use of patterns has become so popular in other areas of programming that many patterns are specific to them and do not apply to object-oriented programming.

Why should I learn design patterns?
#

In truth, it is possible to work as a developer for many years without ever having learned a single pattern. This is the case for many people. But even if you are one of these people, it is highly likely that you use them without realizing it. So why should you take the time to learn them?

Design patterns are a toolkit of reliable and proven solutions used in response to classic software design problems. Even if you have never encountered these problems, knowing the patterns is still useful, as it teaches you techniques for solving all kinds of problems using object-oriented design principles.
Design patterns define a common language that you and your colleagues can use to communicate better. You can say: “Oh, just use a singleton,” and everyone will instantly understand what you just suggested. No need to explain what a singleton is, if you already know its name and principle.

Criticism of design patterns
#

It would seem that only lazy people have not yet criticized design patterns. Let’s look together at the most common criticisms they receive.

Workarounds for poor programming languages
#

We generally resort to design patterns when we choose a programming language or technology that does not have a sufficient level of abstraction. In this case, patterns become a workaround that grants the language absolutely necessary superpowers.

For example, Strategy can be implemented with a simple anonymous function (lambda) in most modern programming languages.

Inefficient solutions
#

Patterns attempt to automate approaches that are already very widely used. This unification is seen by many as dogma, and they implement patterns “to the letter,” without adapting them to the context of their project.

Unjustified use
#

If all you have is a hammer, everything looks like a nail.

This is the problem that will haunt novices who have just become familiar with design patterns. Now that they know them, they will try to apply them everywhere, even in situations where basic code would have sufficed.

Classification of design patterns
#

Patterns differ in their complexity, level of detail, and the scale at which they are applicable to a system being designed. I find the analogy made with road construction quite telling: you can install traffic lights to enhance the safety of an intersection or build a multi-level interchange with underground pedestrian passages.

The most basic and lowest-level patterns are often called idioms. They are generally designed for a specific programming language.

The most universal and highest-level design patterns are architectural patterns. Developers can implement these patterns in almost any language. Unlike other patterns, they can be used to design the entire architecture of an application.

Furthermore, all design patterns can be categorized according to their intent or purpose. This book covers the three main groups of patterns:

Creational Patterns provide object creation mechanisms, which increase code flexibility and reusability.
Structural Patterns explain how to assemble objects and classes into larger structures, while keeping them flexible and efficient.
Behavioral Patterns establish effective communication and distribute responsibilities among objects.