Design patterns

1.1 Introduction to patterns

As mentioned earlier, a programmer begins work on a program by designing its model: compiling a list of entities that the program will operate on. And the more entities in the program, the more complex the program.

Therefore, in order to reduce the complexity of the program, they try to standardize the interactions of objects. And this is where design patterns or design patterns help the programmer a lot . From English design pattern .

Important! In Russian, the word design usually means graphic design, in English this is not the case. The English word design is closer in meaning to the word “design” and / or “device”. For example, the design of an engine is not its appearance, but its internal structure.

Therefore, a design pattern is exactly a design pattern/pattern. I recommend that you stop using the word design in the sense of “appearance” altogether. You are the future Software Engineer, and for you design is exactly design.

So what is this design pattern? First of all, a design pattern is a standard solution to a standard problem . A good, effective and time-tested solution.

Let's say you were asked to design a bicycle, you can make it two wheels, three or even five. So by the way, at the dawn of design, it was. But the time-tested approach is two wheels. But the current obvious approach went through pain and mistakes:

Typically, a template is not a complete solution that can be directly converted to code, it is just an example of a good solution to a problem that can be used in various situations.

Object-oriented patterns show relationships and interactions between classes or objects , without specifying which final classes or application objects will be used.

1.2 History of design patterns

Back in the 70s, programmers were faced with the need to develop large programs that had to be worked on by entire development teams. Various methods of organizing work were tried, but the construction industry influenced the development the most.

To organize the work of a large group of people, practices and approaches from the construction industry were used. By the way, it was from there that such terms as assembly (build), Software Developer (builder), and the concept of architecture came into programming.

And as you might guess, the design pattern idea was also taken from the construction industry. The concept of patterns was first described by Christopher Alexander in The Pattern Language. Cities. Building. Construction". In this book, a special language, patterns, has been used to describe the processes of city design.

Patterns in construction described typical time-tested decisions: how high windows should be, how many floors should be in the building, how much area in the microdistrict should be allocated for trees and lawns.

Therefore, it is not surprising that in 1994 the book “Techniques of Object-Oriented Design. Design Patterns”, which includes 23 patterns that solve various problems of object-oriented design.

The book was written by 4 authors: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. The title of the book was too long for anyone to remember. Therefore, soon everyone began to call it “book by the gang of four”, that is, “a book from a gang of four” , and then even “GoF book”.

And since then, other design patterns have been discovered. The “pattern” approach has become popular in all areas of programming, so now you can find all sorts of patterns outside of object design.

Important! Patterns are not some super-original solutions, but, on the contrary, frequently encountered, typical solutions to the same problem. Good proven solutions.

1.3 List of patterns

Many programmers have not learned a single pattern in their entire lives, which, however, does not prevent them from using them. As we said before, patterns are good time-tested solutions, and if the programmer is not a fool, then with experience he himself finds such solutions.

But why, through dozens of trials and errors, come to optimal solutions when there are people who have already gone this way and have written books with the quintessence of their experience and life wisdom?

You can hammer a nail with a wrench, but why? You can even use a drill if you try hard. But a good conscious possession of the instrument is precisely what distinguishes a professional from an amateur. And the professional knows that the main feature of the drill is not at all in this. So, why do you need to know patterns?

• Proven solutions. You spend less time using off-the-shelf solutions instead of reinventing the wheel. Some decisions you could think of yourself, but many may be a discovery for you.
• Code standardization. You make fewer miscalculations when designing, using typical unified solutions, since all the hidden problems in them have long been found.
• General programming dictionary. You say the name of the pattern instead of spending an hour explaining to other programmers what a cool design you came up with and what classes are needed for this.

What are the patterns?

Patterns differ in the level of complexity, detail, and coverage of the system being designed. Drawing an analogy with construction, you can increase the safety of an intersection by putting up a traffic light, or you can replace the intersection with a whole car interchange with underpasses.

The most low-level and simple patterns are idioms. They are not universal, since they are applicable only within the framework of one programming language.

The most versatile are architectural patterns that can be implemented in almost any language. They are needed to design the entire program, and not its individual elements.

But the main thing is that the patterns differ in purpose. The patterns that we will get acquainted with can be divided into three main groups:

• Creation patterns take care of the flexible creation of objects without introducing unnecessary dependencies into the program.
• Structural patterns show different ways of building relationships between objects.
• Behavioral patterns take care of efficient communication between objects.

1.4 Introduction to UML

Let's start by looking at the same 23 patterns that were described in the Gang of Four book. Both the patterns themselves and their names are familiar things even for a novice programmer. I will introduce you to them, but I strongly recommend reading that very book about patterns.

Design patterns are not tied to a specific programming language, so the UML is usually used to describe them. It was very popular 20 years ago, but even now it is sometimes used. And by the way, the description of patterns is just the place where the use of UML is the standard.

With UML, you can describe relationships between different entities. In our case, these are objects and classes.

Relations between classes are described by four types of arrows:

In fact, everything is very simple here. The last arrow actually means that one class is inherited from another class. And the first and second arrows are that one object stores a link to the second object. And it's all.

If the link diamond is black, then the link is weak: objects can exist without each other. If the diamond is white, then the objects are strongly related, such as a class HttpRequestand its child class HttpRequest.Builder.

1.5 List of patterns

Types of patterns will be denoted by different colors and letters:

B- behavioral (behavioral);

C- generating (creational);

S- structural (structural).

And finally, a list of 23 design patterns: