What are the design patterns for?
More and more often I hear from developers and read in articles that design patterns (they are design patterns) are not needed by anyone. They say that they appeared during the “bloom” of UML, RUP, CASE systems and other overly “complex” tools, approaches and practices. And now the most important thing is to write the worker code, but quickly. Nobody has time for smart fat books, except for an interview. Those who want to discuss this topic, please under the cat.
')
When I was at university, we were taught in one of the courses design patterns. At that time, they seemed to me something like a spherical horse in a vacuum, because I did not have any practical experience with them (it was the third or the beginning of the fourth year many years ago). Remember who of them who was also quite difficult, not to mention the intricacies and details. However, questions on design patterns were asked without fail at each job interview. Candidates had to inflate their cheeks and prove how different templates are cool (especially Singleton), seeing them in life a maximum of a different time on the pages of books.
But after all, not completely stupid people came up with design patterns:
There is no sense to continue the historical chronicles. It was the first book from which our generation drew its knowledge of design patterns and tried to apply them in its work. It is considered a classic in this topic and is required to read.
After a while, I began to notice that even theoretical knowledge of design patterns helps me understand someone else's code much faster . And this is especially important at the start of your career, when you need to delve into existing projects with no work experience. For example, when meeting a class with the Builder suffix, I understood that it was added in order to simplify and isolate the logic of building complex objects. I immediately found how to use it and apply it in my code. Representatives of the Singleton template were scattered everywhere, making an error during initialization of which is so easy without knowing the rules of application. In the code I worked with, Facade, Visitor, Chain of Responsibility, Iterator, Adapter, Decorator, Proxy, Strategy, Template Method and other popular design patterns met abundantly.
I realized how much time I was saving by applying my scanty book knowledge of design patterns and even in my heart I began to respect their authors. It was easy for me not only to understand someone else's code, but also to expand it with my own solutions, as well as add new ones.
Time passed ... I quickly got used to the widespread use of design patterns and it became difficult for me to work without them. I began to understand why during the interview candidates are asked about them (of course, if not just “for show”). Here it is not even about the mandatory use of design patterns, but about simplifying communication between developers. And this is the process that occupies a key place in the development - a discussion of the architecture and design of a specific problem solution.
The first important parameter is the time spent on discussion and decision making (I hope that your decisions are made not by one bearded Senior Senior Global Product Software Architect). Imagine how difficult it would be to quickly explain to someone that the Decorator needs to be implemented: “we need to make a class to which we will pass an instance of another implementation of the same interface to the designer and which will add logic to the call of these methods without changing their basic behavior. .. ”But there were still a lot of small things and nuances behind the scenes. And this is for small details of your design, which in most decisions are dozens or even hundreds. We do not even touch the complex and serious architectural patterns.
Using the Decorator example, it is easy to understand the second important parameter - the same understanding of the problem design in the heads of all team members. With vague wording, everyone can understand the solution in different ways, and this is fraught with problems. After all, the implementation may be very different from the discussed idea. And this will lead to additional time for review of the code and rework.
The third important parameter is the understanding of the work of third-party tools and libraries. At the moment, almost every project uses many third-party solutions. In order to use them correctly and not to step on a rake, the architect and the developer must understand how things work. And for this, well-known patterns are used, which are designed to greatly simplify understanding and compare with alternative solutions.
In life, we actively use examples to describe situations, objects, actions. To explain a concept to someone, we are based on well-known knowledge and build examples based on it. “As healthy as Vasya”, “as hard as after 5 km of jogging”, “bad as a hangover”, “sour as a lemon”, etc. We use such expressions in our speech constantly and do not even notice it. For us, their use is easier than a detailed description and this allows your interlocutor to understand you better.
If you notice that you are not trying to remember the details of the implementation of the design pattern, but you can simply state the details of its use in your own words, then you have exceeded the level of Shu in the well-known Eastern philosophy of Shuhari (I once wrote about its applicability to Agile approaches and practices . At the Shu level, you simply follow patterns and cannot recognize their usefulness, subtlety, and influence. At the level of Ha, you are already aware of everything and can consciously abandon certain patterns, criticize decisions based on them, modify some patterns for a specific situation and context.
On the Ha level, I highly recommend reading the excellent book “Refactoring to Patterns” by Joshua Kerievsky. It tells how to find in the code inappropriate or poorly applied design patterns, and then by refactoring to bring them to the right and appropriate solutions. This book is worth reading at the level of Ha, because before that it will be just an empty sound for you.
What is the level of Ri ? At this level, you completely stop thinking about the use of templates. Solutions are born naturally on the basis of your knowledge and skills that you have gained over the years. Somewhere there are some patterns, somewhere your own developments, which have become templates for you in this context. In your head, the chain “from template to solution” stops working and only “from solution to template” remains. Then, instead of asking questions about specific design patterns at the interview, you go to open questions about the applicability of this tool and real-life examples ...
Design patterns are one of the developer's tools that help him save time and make a better solution. Like any other tool, in one hand it can bring many benefits, and in others it can bring only harm. I tried to convey with examples what exactly the design patterns will give you and how to treat them. I hope I managed it ...
PS At one of my trainings, the book on design patterns for beginners was praised by Head First Design Patterns . I personally did not read it, because I had sufficient knowledge of the topic from other sources and am not sure about this format of books.
Some memories from youth
')
When I was at university, we were taught in one of the courses design patterns. At that time, they seemed to me something like a spherical horse in a vacuum, because I did not have any practical experience with them (it was the third or the beginning of the fourth year many years ago). Remember who of them who was also quite difficult, not to mention the intricacies and details. However, questions on design patterns were asked without fail at each job interview. Candidates had to inflate their cheeks and prove how different templates are cool (especially Singleton), seeing them in life a maximum of a different time on the pages of books.
But after all, not completely stupid people came up with design patterns:
- In the 70s , architect Christopher Alexander started the business and formulated a set of design patterns.
- Back in 1987 , IT was picked up by the infamous Kent Beck and Ward Cunningham , creating design patterns for the popular Smalltalk programming language.
- Another legendary IT man, Erich Gamma, wrote his doctoral dissertation on this topic in 1988-1990 .
- Finally, in the early 1990s, the famous “gang of four” composed of the same Erich Gamma, Richard Helm, Ralph Johnson and John Vlissidsom published the legendary book Design Patterns: Elements of Reusable Object-Oriented Software .
There is no sense to continue the historical chronicles. It was the first book from which our generation drew its knowledge of design patterns and tried to apply them in its work. It is considered a classic in this topic and is required to read.
After a while, I began to notice that even theoretical knowledge of design patterns helps me understand someone else's code much faster . And this is especially important at the start of your career, when you need to delve into existing projects with no work experience. For example, when meeting a class with the Builder suffix, I understood that it was added in order to simplify and isolate the logic of building complex objects. I immediately found how to use it and apply it in my code. Representatives of the Singleton template were scattered everywhere, making an error during initialization of which is so easy without knowing the rules of application. In the code I worked with, Facade, Visitor, Chain of Responsibility, Iterator, Adapter, Decorator, Proxy, Strategy, Template Method and other popular design patterns met abundantly.
I realized how much time I was saving by applying my scanty book knowledge of design patterns and even in my heart I began to respect their authors. It was easy for me not only to understand someone else's code, but also to expand it with my own solutions, as well as add new ones.
And how without templates?
Time passed ... I quickly got used to the widespread use of design patterns and it became difficult for me to work without them. I began to understand why during the interview candidates are asked about them (of course, if not just “for show”). Here it is not even about the mandatory use of design patterns, but about simplifying communication between developers. And this is the process that occupies a key place in the development - a discussion of the architecture and design of a specific problem solution.
The first important parameter is the time spent on discussion and decision making (I hope that your decisions are made not by one bearded Senior Senior Global Product Software Architect). Imagine how difficult it would be to quickly explain to someone that the Decorator needs to be implemented: “we need to make a class to which we will pass an instance of another implementation of the same interface to the designer and which will add logic to the call of these methods without changing their basic behavior. .. ”But there were still a lot of small things and nuances behind the scenes. And this is for small details of your design, which in most decisions are dozens or even hundreds. We do not even touch the complex and serious architectural patterns.
Using the Decorator example, it is easy to understand the second important parameter - the same understanding of the problem design in the heads of all team members. With vague wording, everyone can understand the solution in different ways, and this is fraught with problems. After all, the implementation may be very different from the discussed idea. And this will lead to additional time for review of the code and rework.
The third important parameter is the understanding of the work of third-party tools and libraries. At the moment, almost every project uses many third-party solutions. In order to use them correctly and not to step on a rake, the architect and the developer must understand how things work. And for this, well-known patterns are used, which are designed to greatly simplify understanding and compare with alternative solutions.
In life, we actively use examples to describe situations, objects, actions. To explain a concept to someone, we are based on well-known knowledge and build examples based on it. “As healthy as Vasya”, “as hard as after 5 km of jogging”, “bad as a hangover”, “sour as a lemon”, etc. We use such expressions in our speech constantly and do not even notice it. For us, their use is easier than a detailed description and this allows your interlocutor to understand you better.
Next level
If you notice that you are not trying to remember the details of the implementation of the design pattern, but you can simply state the details of its use in your own words, then you have exceeded the level of Shu in the well-known Eastern philosophy of Shuhari (I once wrote about its applicability to Agile approaches and practices . At the Shu level, you simply follow patterns and cannot recognize their usefulness, subtlety, and influence. At the level of Ha, you are already aware of everything and can consciously abandon certain patterns, criticize decisions based on them, modify some patterns for a specific situation and context.
On the Ha level, I highly recommend reading the excellent book “Refactoring to Patterns” by Joshua Kerievsky. It tells how to find in the code inappropriate or poorly applied design patterns, and then by refactoring to bring them to the right and appropriate solutions. This book is worth reading at the level of Ha, because before that it will be just an empty sound for you.
What is the level of Ri ? At this level, you completely stop thinking about the use of templates. Solutions are born naturally on the basis of your knowledge and skills that you have gained over the years. Somewhere there are some patterns, somewhere your own developments, which have become templates for you in this context. In your head, the chain “from template to solution” stops working and only “from solution to template” remains. Then, instead of asking questions about specific design patterns at the interview, you go to open questions about the applicability of this tool and real-life examples ...
Conclusion
Design patterns are one of the developer's tools that help him save time and make a better solution. Like any other tool, in one hand it can bring many benefits, and in others it can bring only harm. I tried to convey with examples what exactly the design patterns will give you and how to treat them. I hope I managed it ...
PS At one of my trainings, the book on design patterns for beginners was praised by Head First Design Patterns . I personally did not read it, because I had sufficient knowledge of the topic from other sources and am not sure about this format of books.
Source: https://habr.com/ru/post/170125/
All Articles