Abstract: Many people have some questions about design patterns: Do you have to use design patterns to write code? Is code that uses design patterns better than code that doesn’t?
This article is from the huawei Cloud community “Approaching Design Mode: Is It necessary to write code in Design Mode?” Torchbearer of technology.
A lot of people have questions or questions about design patterns:
1. Do I have to use design patterns to write code?
Is code that uses design patterns better than code that doesn’t?
To answer the first question, we need to investigate what design patterns are, including understanding why design patterns are created and whether they can help us solve software problems. To answer the second question, you need to know how to use design patterns, when and where to use them, when to use them, and when to stay away from them.
What are design patterns?
I was interviewing candidates a while back and asked this question — “What are design patterns?” . The candidate replied, “Design patterns include singleton, observer, and proxy patterns…… “. I did not interrupt him, but went along and asked him what he understood about these patterns. That’s not what I wanted to ask, but I’m guessing there are plenty of people who would answer that question.
“Design Patterns,” or “Design Patterns,” are nothing more than Patterns of Design — software Design, and more specifically, “object-oriented software Design.” Patterns are more general. There are Patterns in every industry, and in the vernacular they are “Patterns” — experiences that can be replicated.
When it comes to design patterns, there is a classic book called Design Patterns: The Foundations of Reusable Object-oriented Software. In addition to design patterns, there is a subtitle — The Foundations of Reusable Object-oriented Software, which defines reuse and object-oriented. The book starts with a few ideas:
Designing object-oriented software is difficult, and designing reusable object-oriented software is even more difficult.
2. Experienced object-oriented designers can make good designs, while novices can’t.
3. Instead of starting from scratch to solve any problem, expert designers prefer to reuse previously used solutions.
It then gives a definition of a design pattern that is not well understood: a description of classes and objects that communicate with each other to solve common design problems in a particular scenario. Speaking is a reusable solution to a particular problem. The concept of reusable here is vague, and I prefer to think of it as best practices for solving specific problems that have been developed in real projects.
This best practice can be derived from others, typically from books and source code; A more important source is the summary of my own software development experience.
What patterns are used when?
Best practices for solving specific problems. Obviously the best practices for solving problem A are not always the best practices for solving problem B, at least not the best practices for solving problem B, so I think there are at least two problems here:
1. What problem does a design pattern solve?
2. Is my problem equal to the problem solved by a design pattern?
With the answers to the above two questions in mind, what follows is how design patterns solve my problem.
These two questions are raised from my thinking, and I also think they are two terrible questions. I will explain them below.
First of all, I don’t recommend beginners learn how to use various design patterns, such as those 23. Learning often results in learning how to implement a design pattern in a programming language without being impressed with what problems the pattern solves. Such preconceptions lead scholars to think that design patterns are simple, and then use them for the sake of using them in actual development, without solving the real problem. Because THAT’s what I did, I thought there was a better way.
One suggestion is to follow these steps to learn design patterns as a beginner:
1. Take the time to understand common design problems and complications in software design
2. Which problems already have best practice solutions, or design patterns, and which do not
3. Deeply understand how design patterns solve this problem, and preferably participate in the process
The idea is that there is a problem before there is a pattern, and the idea that is formed in the brain is through the pattern of problem retrieval, not through isolated patterns, or the pattern of problem retrieval circuit.
Here we are looking at the above two questions, is a kind of thinking to find the answer to the question. The actual scene should hold the question to find the answer. Let’s recalibrate:
1. What’s the problem I’m trying to solve?
2. Is my problem equal to the existing problem A
3. Is there A design pattern to solve problem A
We can only answer question 3 by learning what common design problems are and the corresponding patterns.
Questions 1 and 2 have nothing to do with design patterns, but are the first steps to applying a design pattern. This is also the root cause of design pattern abuse and the reason why many people abandon design patterns.
As for how to answer these two questions, I can’t give you any answers. The ability to analyze problems may need time to accumulate.
A cage of design patterns
There is nothing wrong with design patterns being defined as best practices for solving a particular problem, but often people get trapped in design patterns.
Take GoF design patterns, for example. While those 23 design patterns were developed by smarter programmers than you and I, they are not without costs.
1. Design patterns are not off-the-shelf code, unlike class libraries that can be used directly
2. Design patterns mostly solve the problem of code extensibility, but here extensibility is really what you need, is not excessive design
3. Design patterns often improve extensibility by increasing abstraction at the expense of simplicity
Here are the first two questions:
Q: Do I have to use design patterns to write code?
A: No, not every problem has a ready-made solution.
Is code that uses design patterns better than code that doesn’t?
A: No, maybe worse.
Learn the benefits of design patterns
While design patterns are not a silver bullet, and knowing them won’t necessarily help you solve the problems you’re facing, learning them can be a great help in your software development work, even if you never use them.
If you do not deceive the reader to learn this or a bit of use, that write the follow-up series of articles where the meaning of……
1. Respond to interview questions about design patterns
It’s pretty straightforward, if you’re being interviewed, there’s a good chance you’ll be asked; If you’re interviewing people, this can be used to test the candidate’s understanding.
2. Let read the source code, learning framework twice the result with half the effort
A good open source project will have a large number of classes, and the class structure and relationship between classes are extremely complex, often called to call. In order to ensure the extensibility of the code, the code will use a lot of design patterns, of course, does not exclude the suspicion of the author show, but if you do not understand the design pattern, look at the open source code often can not feel the author’s design ideas, it seems to find the north.
3. Lay the groundwork for your career
In the code review of the company, you can’t even name a few design patterns, so you are not a “big dog”. Yeah, that’s it.
4. Improve your code design skills
It’s a matter of nature, but it’s a fact of life, and there will always be times when you need to design complex systems.
Click to follow, the first time to learn about Huawei cloud fresh technology ~