Analysis and implementation of design patterns (c + +) 21-end

One months down, the common 20 design patterns have been reviewed and implemented in C + +, the harvest is still very big, a lot of things seem to understand but really do do when found in fact still do not understand-I know this truth, so dare not snub, do not dare to write what the so-called interpretation of the principle of pseudo-code, Dare not say the so-called "know the principle can be" .... Because I know, I have not yet qualified to say this, at least for the design model I am still a beginner, only practical and hard to slowly grasp the knowledge.

In the process of learning design patterns, I feel that the main cause of understanding is the following points, to talk about their own experience, hope to help others, do not embark on my old road, after all, I spent n long time to dare to claim that I started the ~~!! -_-:

1) Gof is not suitable for beginners. Learning design patterns are generally from the beginning of the introduction of GOF to learn, unfortunately, this is not a good textbook, and the book is called the one that lays the foundation of the design pattern. Perhaps better, it collects the common patterns scattered in various designs, Since then, there is a noun called "design pattern". That this book is not a good textbook is mainly due to the following reasons: a It is not enough to explain the design pattern or some principled things in object-oriented, for example, "interface-oriented programming rather than implementation programming", Take precedence over the combination rather than the inheritance "and so on, so that when you see the implementation of the various patterns, many patterns look similar but can not find the difference and common place. b The explanations of each model or the examples given are not particularly good, most of which are explained in the form of explanations, without adding to the considerations of some of the basic principles mentioned above, that is to say: the original reason and the realization (each design pattern) are disjointed.

2 Beginners have a bad understanding of language or some concepts. C + +, in order to achieve the object-oriented need to provide support for the language of inheritance, polymorphism, encapsulation, virtual functions, abstractions, etc., I used to learn C + +, just to study these concepts and to learn, do not know why to provide these characteristics, This is one of the important reasons for my detours. Of course, it's hard to expect a beginner to know why in a beginner's language, and perhaps a combination of understanding the design pattern can help you digest these concepts (I am).

3 can not understand the UML structure diagram and time series diagram, UML diagrams explain the relationship between classes and classes, the sequence diagram is to explain the implementation of the various objects, the combination of both to deepen the understanding of the design pattern, in fact, I can now do just look at the two diagrams to grasp the principle of a pattern and implementation.

4 write code and participate in a number of projects not enough. Design patterns and a lot of things are the same as the production process, first people encounter problems, and then a lot of people solve the problem, and gradually someone came out to solve these problems to comply with some of the principles and common methods (we call it "mode"), Over time it has formed a theory or a discipline. The latter are mostly scripted when it comes to telling these theories, which is difficult to understand in a theory such as computer-emphasizing practice, or in terms of design patterns. Some considerations were made by predecessors in proposing these theories, Trade-offs and so on. Only when you encounter these problems can you slowly experience. There is a saying that you don't have to write 10W lines of code. Don't talk about design patterns.

To sum up, the reason for beginners to learn the design pattern is difficult, one is to understand the basic principles is not thorough, a choice of introductory textbooks unreasonable, there is a statement of the various patterns do not understand, again is not enough practice.

There are a few books that I have read and I would like to talk about my views.

The first,<< Agile Software Development: principles, patterns and practices >>, the most important contribution of this book to the design pattern is that there are several chapters devoted to several object-oriented principles, such as the Likov principle, the open closure principle, etc. These chapters play a key role in my learning of design patterns, because when I understand these principles, I begin to understand why there are pure virtual functions that provide interfaces, why they have abstract base classes, and why they encapsulate .... I began to use these principles to understand the various design patterns, began to slowly realize the differences and similarities between the various patterns.

In addition to the two books I have read, I think the nature is the same, if you are short of money, choose one. The first one is the << Design model refined Solution >>, the second is the << design model >> It's all the books that I can finish in a couple of evenings. Both of these are based on vivid examples of object-oriented principles to explain the pattern, I prefer the former (the latter is too expensive, if not 50 percent I do not buy na):

Secondly, to contact the project more or to find some good code to see, write some more code yourself. Basically, as long as it is a project developed with object-oriented language, it is impossible to use a few patterns. So, to get rid of the illusion that you want to understand when you start contacting design patterns, Because to really understand the need for a lot of practice, the same 1:30 will not understand also do not have to be discouraged (Gof e version I read many times:), firmly believe that their practice can be slowly enlightened.

One question about design patterns: Are there any so-called "design patterns" in non-object-oriented languages? Design patterns are initially defined as idiomatic ways to solve some problems (to the effect), and there is no explicit need to support the language of an attribute. The project I developed with pure C is really limited, Usually just do some small things to play, did not do any of the tens of thousands of lines of pure C development projects, so has been a question on this issue ~~anyway, there are problems is good, indicating that I think ~ ~ Put this problem here, after the practice of thinking slowly ~ ~

Bo Jun a smile.

About design patterns, there is an interesting article--<< chasing mm and design mode >>, this article is "entertaining" model, tells the 23 models in the daily life of the prototype, although not specifically described how to achieve, However, it is helpful to understand the application of various design patterns. Believe that the design pattern has already had a certain understanding of people read this article will know a smile: the author and the source has been unknown.