It took me about a month and a half to buy all of the more famous book of design patterns on the market. I learned them again and again. These books are both good and bad.
if you want to learn the system design pattern, I suggest to buy books, because the book knowledge system and authority, unlike online articles although there are a lot of uneven in quality, some blog article is good, but just began to have no ability to distinguish.
This article should be a warm-up to learn design patterns and give you a general idea of the design patterns.
I’ll write most of the design patterns separately, and the code and the text of these articles are written in my own books. If there is any deviation, please correct me.
What is design pattern?
In software development, a proven solution for solving specific problems that occur repeatedly in a particular environment.
Pay attention to the mentioned qualifier, and below, in detail
1, software development:
, in fact, all walks of life have patterns can be applied, the design patterns here refers to the field of software development
must be recognized and proven solutions are considered design patterns, rather than everyone casually summed up the solution can be counted
3, the specific environment:
must be in a particular environment can use the design pattern, because of the different environment, even if the same problem, solutions are also different, so can not be separated from the environment to talk about the use of design patterns
because the only recurring problems it is necessary to sum up the experience, the formation of fixed solutions, once again encountered such a problem would not start looking for the solution from scratch, but directly apply can.
5, specific problem: there is no silver bullet field of
software development, don’t expect a design pattern can cure. Each pattern is just a solution to a particular problem, so don’t be superstitious about design patterns and misuse design patterns.
Each design pattern is organized as follows:
1, schema name: a well remembered name for the schema
2. Environment and problems: describe what specific problems arise in what circumstances
3. Solution: describe how to solve the problem
4: effect: describe the effect of the application pattern, and possible problems
Why do you want to learn design patterns?
Quote a passage from above:
This passage is very good summary of learning path design pattern, this is in your long time steeped in the field of programming, then one day his insight, which need long time and understanding. But now you have a design pattern that allows you to understand the programming ideas more quickly with borrowed experience.
We all know that SOLID six principles of object-oriented design, just follow these principles, we can achieve the code reuse, increase maintainability, thereby increasing the reusability, easy to modify, later extended.
But this principle is too abstract, you do not have a few years of project combat, can not understand thoroughly, and this requires savvy.
If SOLID is the internal strength of software development, then the design pattern is martial arts moves, the SOLID principles show the moves, the idea into the actual scene of the application code.
By learning these design patterns, you can find the “package change”, “loose coupling”, “programming for the interface” feeling, so as to design a program that is easy to maintain, easy to reuse, good scalability and flexibility.
Experts are the first to imitate, and then understand, and finally self created. As the saying goes, “read the three hundred Tang Poems” is the truth.
Not to say that you can learn these 23 kinds of design patterns (design patterns are also more than this 23) you can solve any problem in the field of software, but by allowing you to understand the idea of object-oriented programming and design pattern learning (SOLID) to the end, you can abandon the design pattern, applying these ideas in your code. Write high cohesion and low coupling, scalable and easy to maintain code. At this point, there has been no design pattern in mind, but design patterns are everywhere. This is the purpose of learning design patterns.
The completion of the design pattern is just the first step, and not let your encoding level has been a qualitative leap, then you need to digest the essence of these design patterns through a lot of practice, into their own thoughts, which is reflected in the code.
How to learn design patterns
The following are excerpts from the book “design patterns” grinding
1. learn the three levels of design patterns
2. how to learn design patterns
If you read the above content, I think it is necessary to learn design patterns to improve their internal strength, then you can continue to look at.
My study suggestion is as follows, is also to these several books appraisal, everybody may make a reference
1 “head first” design pattern, the recommended index: every every every every
It is recommended to read again and again, and then manually execute all the code once. Although the book is written in Java language, if there are other language base, it seems basically difficult.
This book is really easy to understand, and in simple and easy language, the design pattern of such a high degree of abstraction of knowledge is very thorough. However, it is estimated that many people do not like the style of cartoon and dialogue, but when you get used to it, you find it more efficient to learn than literal writing. Because the human brain’s memory of images is always deeper than words, the book doesn’t finish the 23 design patterns.
2 “grinding design mode”, recommended index: every every every every every
If I want to score these books, I would like to give full marks to this book. I wonder if people in China can write such good technical books. The beauty of the book is that it not only explains the 23 design patterns of GOF in detail, but also writes it very well.
First, throw out a real problem, then list the common solution, then what happens to the regular solution, and naturally draw the corresponding design pattern to solve. There is a comparison process that can help us understand why design patterns are used.
This book is so brilliant, there are probably the following points:
1> most of the examples in the book is to solve the practical problems encountered in the development, although there are no Java backend, what big significance for us to the iOS side, but we can learn to use design ideas to solve the problem, so as to realize the mode of the essence, be of great advantage.
2> each model has been extended in depth; other books either simulate pseudo code using patterns, or explain it in depth. But this book is basically a thorough explanation of each model, analysis of the pros and cons of each model, apply the scene, if the deformation of the use of
3> for each pattern, it explains how to use it in conjunction with other patterns, and makes a detailed comparison of similar patterns.
Based on the above three points, I think this book deserves the best in the audience. But unfortunately, this book printed online basically not buy, estimated sales is not good, do not press the book, originally wanted to buy a treasure, often read, fear not liking, have to say sorry. Although this book is not as large as other books, it should be the best in terms of content. If you just want to read a book, I recommend this book, you must see it!!
3 “Zen Design Model”, recommended index: every every
The content of the book, I am sorry, the title of the book, at first glance, this title should be in-depth study of design patterns. But really open a look, found that each is tasted, even giving you the pseudo code throws a design pattern, do not explain why write this. Some text examples is very inappropriate, forced the examples and design patterns. It is neither fish nor fowl.
Even the essence of the book mentioned in the preface is the design patterns and extensions of the book. Just a few pens, and said and did not say the same. As for the book killer: PK design pattern and design of mixed mode. Is a general, merely mediocre.
Of course, this book is not nothing, the first part, I think it is the essence of this book, explained in detail the SOLID design principles, you can take a good look at. The SOLID section of this blog also draws on this book.
The “big 4” design pattern, Recommendation Index: every every every
This book should be the simplest of all the books. If you have trouble reading other books, you can read the book first. But this book is very simple, just let you know each design pattern of the realization of pseudo code and function, read, there is a general understanding, no further explanation.
Although the book’s online evaluation is very high, I don’t think it’s necessary to read it. The reason is really too simple, read on design patterns or smoke and mirrors, unsuspectingly. To get started, head first is recommended.
5 “design mode”, recommended index: every every every every
This book is the originator of other books, GOF original. However, this book is very concise, coupled with the code is c++ implementation, if you have not touched the design pattern, basically do not want to understand this book.
Not recommended as an entry book. You can read the other books and look back at the book. This book made a very refined description of each design pattern, the essence of the book in the first chapter, the object oriented design field to do a lot of guidance to sweep down irresistibly from a commanding height is worth reading. “Grinding design model” is a detailed interpretation of the book, if the former understand, this book basically does not need to look at.
6 design patterns “meditations”, recommended index: every every every
The book, written by one of the GOF authors, explains some of the misconceptions about design patterns, and then gives some advice on how to use the design patterns. You can see.
7 “Objective-C programming: IOS design pattern analysis”, recommended every index:
A lousy book!!
The first translation is pulpy, statement is unreasonable, do not know what to write. Secondly, although this book is written for iOS, but no iOS in this particular field to explain the design pattern, cry up wine and sell vinegar, for example not practical, but a few still use a bit.
Even more wonderful is that many places are forced to use design patterns, the original implementation of a simple change is very complex, full of support. Design patterns solve problems, not manufacturing problems.
Anyway, a lousy book is not recommended.
How to read a Book
Tucao finished, said my learning suggestions:
High level: just look at a “grinding design patterns” enough, the book repeatedly through, and other basic need not read.
Middle grade: “head first design pattern” ——-> “lapping design pattern”
Intro: “lying design patterns” —-> “head first —->” design pattern “design pattern”; grinding
The book, just know there is such a thing, how to use, we need to see the beauty and essence of open source project area understand the design pattern, you will see all kinds of design patterns exist in the framework of open source projects, there is a direct use of some deformation.
Read more, write more, think more.
Classification of design patterns
Now let’s have a perceptual understanding of the design patterns.
A brief description of each design pattern is given:
The 23 design patterns of GOF are shown below:
As shown, the design patterns are divided into two dimensions: purpose and scope.
According to the goal, we can divide the models into three categories: creation, structure and behavior
According to the scope, it can be divided into two major categories: object and class.
The detailed description is as follows: from the book “design patterns”
Association between design patterns:
Object oriented design principles SOLID
The SOLID principle is designed to write reusable, extensible, highly cohesive, low coupling code.
The principle is only the guidance of the strategic level, no code can fully abide by the five principles, and should be rationally chosen according to the actual situation.
Let’s take a look at the specific description of SOLID:
1, single responsibility
A class is responsible for only one type, and this class needs to be broken up when the class needs to assume other types of responsibility. In real development, however, this principle is the least likely to follow because each person has the same type of responsibility judgment for which functions of a class are different.
2, open closed principle
Software entities should be extensible and not modifiable. That is to say, when you write a class, you want to add functionality, you can’t modify the original class, but you can think of ways to extend the class. There are multiple design patterns that can meet this requirement.
3, the Richter scale replacement principle
When an instance of a subclass should be able to replace any instance of its superclass, there is a is-A relationship between them. That is, where the interface or parent class appears, the class or subclass that implements the interface can be substituted, depending largely on polymorphism and inheritance.
4, the interface separation principle
You cannot force users to rely on interfaces that they do not use. In other words, using multiple specialized interfaces is better than using a single general interface. Do not provide a large interface, including all functions, should be based on the function of these interfaces segmentation, reduce dependence.
5, relying on Inversion Principle
- Higher level modules should not rely on lower level modules, and all two should rely on abstractions
- Abstractions should not depend on details, but details should depend on abstractions
The five principles mentioned above are very abstract and are the guiding principles of object-oriented design, and we can design beautiful code only if we follow these principles as much as possible.
Design patterns are the concrete realization of these abstract ideas. Understanding each design pattern can deepen our understanding of these principles and help us improve our internal skills.
When we write the code of the most painful is to demand, because every time to demand, will lead to code big changes, so we should often change places package, let these local changes do not affect other places. This is the main function of design patterns.
Here’s a look at the changes in each design pattern package:
Want to say finally is, learning design patterns, also don’t matter what occasions should put on the design pattern, it has forced. If you write code that does not require the use of design patterns, it shows that no design mode, when code refactoring, design patterns need to use, if you just never mind that private practice.
Design pattern is a long process, after reading the book about the use of each design pattern has just begun, then you need to repeatedly thought, temper, to learn these patterns into thought, reflected in the code.
What a long long road!
Later, I will write a series of design patterns, and strive to make each model clear, what is wrong, please correct me.