Abstract: Many people have some questions or doubts about design patterns: Do you have to use design patterns to write code? Is code that uses design patterns better than useless code?
This article is shared from Huawei Cloud Community " Approaching Design Patterns: Do I Have to Use Design Patterns to Write Code? , original author: technical torchbearer.
Many people have some questions or doubts about design patterns:
- Do I have to use design patterns to write code?
- Is code that uses design patterns better than useless code?
In order to answer the first question, we need to investigate what a design pattern is, which includes understanding the original intention of the design pattern, whether the design pattern can help us solve software problems, etc.; and in order to answer the second question, we need to master how Use design patterns, when and where to use which design patterns, when to use them, and when to stay away.
What is a design pattern?
I asked this question when interviewing candidates some time ago-"What is a design pattern?". The candidate replied, "The design patterns include singleton pattern, observer pattern, agency pattern...". I didn't interrupt him, but went along and asked him his understanding of these modes. Although this is not what I want to ask, I guess there are many people who will answer this way.
"Design Patterns" or "Design Patterns" is nothing more than a design pattern. Design here refers to software design. More specifically, it is "object-oriented software design". The concept of pattern is relatively general, and it is available in all walks of life. Model, in the vernacular, is a "routine", an experience that can be copied.
When it comes to design patterns, there is a classic "Design Patterns: The Foundation of Reusable Object-Oriented Software" that cannot be avoided. In addition to design patterns, there is also a subtitle—The Foundation of Reusable Object-Oriented Software, which limits reuse and orientation. Object. The book first throws out a few points:
- Designing object-oriented software is more difficult, but designing reusable object-oriented software is even more difficult.
- Experienced object-oriented designers can make good designs, but novices can't start.
- It's not that you have to start from scratch to solve any problem. Expert designers are more willing to reuse previously used solutions.
Then it gives a definition of a design pattern that is not well understood: a description of the classes and mutual communication objects used to solve general design problems in specific scenarios. Speaking is a reusable solution . The concept of reusability here is rather vague, and I prefer to understand it as the best practice for solving specific problems summarized in the actual project
This kind of best practice can come from the summary of others, the typical source is a variety of books and source code; there is a more important source is the summary of your own software development experience.
When to use which mode?
Best practices for solving specific problems. Obviously the best practice for solving problem A often does not solve problem B, at least not the best practice for solving problem B, then I think there are at least two problems:
- What problem does a certain design pattern solve?
- Is my problem equal to a problem solved by a certain design pattern?
After getting the answers to the above two questions, the next step is how the design pattern solves my problem.
These two questions are based on my thinking. At the same time, I also think these are two very bad questions. I will explain them below.
First of all, I do not recommend that novices directly learn how to use various design patterns, such as the 23. The result of learning is often to master how to implement a certain design pattern in a programming language, but is not deeply impressed with what problems the design pattern solves. This kind of preconceivedness will make scholars think that the design pattern is very simple, and then use the pattern in actual development, and it does not solve the actual problem. Because I did it this way, I think there is a better way.
One suggestion is to follow this step to learn design patterns at the novice stage:
- Take more time to understand the common design problems and
- Which problems already have best practice solutions, or design patterns, and which ones are not yet
- deeply understand the process of design patterns to solve this problem, it is best to be able to personally participate in the process
This idea is that there are problems first and then there are patterns. The idea formed in the brain is to retrieve patterns through questions, rather than isolated patterns, or loops of pattern retrieval problems.
Here we are looking at the above two questions, which is a way of looking for questions with answers. The actual scene should take the question to find the answer. Let's re-adjust it:
- What is the problem I want to solve?
- my question equal to an existing question A
- there a design pattern to solve problem A
By learning what are the common design problems and corresponding patterns, we can only answer question 3.
Question 1 and question 2 have nothing to do with design patterns, but they are the first step in whether a certain design pattern can be applied. This is also the root cause of the abuse of design patterns, and it is also the reason why many people abandon design patterns.
As for how to answer these two questions, my brother is temporarily unable to answer everyone. The ability to analyze problems may take time.
The cage of design patterns
There is nothing wrong with defining design patterns in terms of best practices for solving specific problems, but there are often people trapped in the cage of design patterns.
Take the GoF design pattern as an example. Although the 23 design patterns are summarized by programmers who are smarter than you and me, using them is not without cost.
- The design pattern is not a ready-made code, it is not like a library that can be used directly
- Design patterns are mostly to solve the problem of code scalability, but is the scalability here really what you need? Is it over-designed?
- The way design patterns improve scalability is often to increase abstraction, which sacrifices simplicity
Let's take a look at the two questions at the beginning:
Q: Do I have to use design patterns to write code?
Answer: No, not all problems have ready-made solutions.
Q: Is code that uses design patterns better than useless code?
Answer: No, maybe worse.
The benefits of learning design patterns
Although design patterns are not a silver bullet, and mastering design patterns may not help you solve the problems you are facing, but learning about design patterns is of great benefit to your software development work, even if you never use it.
If you don’t fool the readers, it’s still useful to learn this, so what's the point of writing a follow-up series...
1. Respond to questions related to design patterns in interviews
It is very straightforward. If you are being interviewed, the probability of being asked is not low; if you are interviewing others, it can be used to examine the candidate's understanding.
2. Make reading source code and learning framework more effective
The number of classes in an excellent open source project is relatively large, and the class structure and the relationship between the classes are extremely complicated, and they are often called. In order to ensure the scalability of the code, many design patterns are used in the code. Of course, the author's show is not ruled out, but if you don’t understand the design patterns, you can often not touch the author’s design ideas when you look at the open source code. .
3. Pave the way for your career development
In the code review of the company, you can't even tell a few design patterns. At first glance, you are not a "big cow". Well, that's it.
4. Improve your code design ability
This depends on good fortune, but it does exist objectively. When you need to design a complex system, get in touch and prepare early.