Let alone the design pattern.

Document directory

• Semantics is 1000 times more important than UML
• Some other models and misunderstandings
• Conclusion

If you don't write a blog for too long, you don't even know what to start.

The main reason is that there are too many articles in this design model, and there are various misinterpretations. the readers are upset and can't help but think about writing a series to make them clear, how can I clearly understand GoF? How can it be influential? What can I do if there are so many people messing around? So after thinking for a long time, I thought it was better to write an article. --!

When talking about the design pattern, many netizens told me that it is really wrong to call it a design pattern. I also feel the same way. The word pattern has the meanings of texture and pattern. When foreigners buy cloth and curtains, they may pick pattern. It is said that pattern is a bit too much, therefore, I think it is better to translate this item into "23 strokes of Object-Oriented Design". This is also a comparison with the best-selling books such as "50 cases of webpage special effects.

Although some students are dissatisfied with the "design pattern", they think that some modifiers should be added when talking about it, but for the sake of simplicity, we agree that all the mentioned "design patterns" refer to the GoF23 model.

The design pattern is intended for object-oriented design issues.

Another huge problem with the design model is that it puts the two important keywords of object-oriented and software into the subtitle, the author also talked about a lot of things such as the mode and architecture. It seems that this book has exceeded the restrictions on language and scenarios, "is a programming idea" (I think that the most common way for masters to cheat New users is to say "language is a cloud, and programming is the most important. "), As long as you write a program, you must model something. Of course, GoF certainly did not mean to lie to everyone. In fact, it can only lie to the children who only read the title and even the subtitle. If they read the content, they will not make a mistake.

However, I am surprised that there are not a few people who don't even look at the subtitles. There are really a lot of people who have to use methods that have nothing to do with object-oriented design patterns ......

After talking about it for a long time, what I want to talk about here is that the design mode is a special skill in object-oriented programming, it is a solution to some difficult design problems arising from the application of the five basic principles (single responsibility, open and closed, Lishi replacement, interface isolation, and dependency inversion. In some non-pure object-oriented languages, there may be no need for design patterns.

An obvious example is that the abstract factory, factory method, and prototype modes solve the problem of creating objects after DIP applications.

A lot of articles, No matter what DIP, refer to a bunch of so-called "Examples of Life", such as the copy jobs of the mechanical and mechanical parts for Hamburg, Nima, this has nothing to do with those lives. Isn't a programmer's life a program? Isn't DIP necessary to write programs? DIP is used to rely only on interfaces. This mode is not required for the new model. The business that people's model name contains the words factory did not hear about implementation must be related to production.

Based on this unknown logic, these models can also be used in JS and C, because JS will inevitably describe McDonald's. As a result, these models have become Lili as an idea, and the abstract factory has become "business logic that describes an object and can generate another object ", the prototype is changed to "describing the business logic of an object that can copy itself, these business logic models can be twisted to fully conform to the class structure of the UML diagram on the GoF .....

Speaking of the case, since there are several models introduced only by following DIP, there is no need to use them in the JS object-oriented language without interfaces. (But interestingly, the prototype in JS is almost the only way to create objects. It has nothing to do with the topic of this Article .) C ++ has the powerful features of templates, and does not need simple factory and factory methods to a large extent (Abstract Factory is still needed ). Similarly, the observer mode is not necessary in C # With delegate and Event.

Semantics is 1000 times more important than UML

The most difficult misunderstanding in the design pattern is the UML. If any article about the design pattern is unreliable, the UML is also true ...... well, the fact that UML is correct is too easy. For example, the policy mode and state mode are basically the same as the bridge mode UML.

Well, so the ghost thing appeared, for example, http://en.wikipedia.org/wiki/Strategy_pattern in the case of comparing strategy and bridge in the end what is different. Nima !!!! Why don't I understand what a product is called "Implementation" or "algorithm"? Is there a crossover between the two products?

Looking at UML alone is a common problem of many design patterns. Well, in general cases, "Examples in life" will appear again, and the semantics will be beautifully ignored. The two most miserable modes are the policy mode and bridge mode. It seems that the words "algorithm", "Implementation", and "abstract" are not very easy to understand. In order to "live", such as oil and salt, completely unrelated functions are put on the algorithm hat, goF said "This mode allows algorithms to change independently of their clients." The Client means that it is helpless and you just need to change the algorithm, what happened when all the links have changed? I just calculated a + B. Nima, you changed the algorithm result to a * B? (Well, I'm talking about the http://en.wikipedia.org/wiki/Strategy_pattern.) Do you want to say that a + B and a * B are calculate? Why don't you simply call all methods dosomething, so that all things in the world can be called different strategies!

The bridge mode is even more tragic. How do the words "abstraction" and "Implementation" look like interfaces and specific classes? It's hard to say that the bridge mode is actually LSP? Another look at UML is really simple. Isn't it a combination? So we messed up a "example in life" and turned UML into a correct one! I admit that the two words in English are a little like implementing interfaces and abstract classes. It is no different to translating them into Chinese. But isn't there another tmd example in GoF? Is there another explanation? How obvious is the example of GoF's Window, abstraction is business-related, and implementation is related to the underlying system.

Some other models and misunderstandings

Flyweight is often used as an example of a C # string to create a "mysterious memory saving solution", or a memory pool as an example to create a fake object with only an external state. The key factor for realizing the correct Flyweight mode is whether the internal and external States are enabled.

The Composite mode is often misunderstood as a tree structure. The key to identifying the Composite mode is the semantics. whether the combination of several X is still X, rather than being included by X. For example, the combination of several geometric figures is still a ry, and the combination of several HTML nodes is not an HTML node.

The Decorator mode is often used to construct strings. (Nima, it is still handed over to something like StringBuilder ......), the key to identifying Decorator is to describe the class rather than the method, and whether the semantics can be re-decorated.

Conclusion

Design is difficult to express in words, so it is very difficult to clearly describe design, I often go to negative comments on design patterns articles in the blog garden ...... however, it has been often "not for patterns" and "your understanding of design patterns is limited to GoF" and "as long as you follow the basic design principles ". (I have been immersed in the culture of "no moves, no moves, no moves" for too long. As a result, we have not yet learned to do so. First, we have no moves ......) one of the purposes of the design model is to provide a set of general design terms, but it is clear that today (at least in our country), it is all distorted and misunderstood. I hope everyone can work together. First, they will set an example and write articles more rigorously. Second, they will polish their eyes, check more information when reading articles, and eliminate all kinds of misunderstandings in the design model.

I attached a picture of my design patterns book To prove that I did read GoF (click it)

 

I read some comments from my friends and thought it was necessary to mention them,

Writing this article is definitely not intended for beginners not to write design patterns.

What I want to express is that when reading and writing articles (not limited to the design model), we should be more rigorous and hard-to-understand. We should not be vague or even take it for granted, it is easier to make progress.