Understanding Design Pattern

Document directory

• What is Design Pattern?
• Why Design Pattern?
• Debate on Design Pattern

The purpose of this article is to understand what Design Pattern is, why Design Pattern is needed, and debate about Design Pattern in the most refined language.

What is Design Pattern?

Literally, Pattern refers to a reusable solution to common problems. The Pattern here serves the Design of the software. Therefore, the so-called Design Pattern refers to a reusable solution to solve common software Design problems, or a solution template.

 

Note the following two points:

1. The algorithm is not Design Pattern.
2. Design Pattern SERVES Design rather than implementation.

I have to mention a book about Design Pattern: Design Patterns: Elements of Reusable Object-Oriented Software, also known as Gang of Four or GoF. Why? This book is so famous that many people have heard that they are familiar with Design Pattern. They all use it, and even think that the so-called Design Pattern is 23 Pattern in GoF. This is a big misunderstanding. Similarly, many people refer to the Design Pattern principle, which is also a misunderstanding. SOLID is the basic principle of object-oriented Design, not the basic principle of Design Pattern, only because GoF is an object-oriented Design Pattern, Pattern in GoF naturally needs to follow the object-oriented SOLID principle.

 

For different software development fields, there are actually many Pattern summarized by our predecessors. For example, GoF is actually a typical object-oriented Design Pattern. It is a typical Pattern summarized by previous people from the object-oriented Design practices. In addition, there are Pattern for architecture design, Pattern for enterprise integration, Pattern for SOA, and so on. Maxcompute Martin Fowler maintains the Catalogs of Deisng Pattern in different development fields that he is personally interested in.

 

Pattern is only a reusable solution for different scenarios. Therefore, you do not need to worship or even myth any existing Pattern. Once the problem scenario of a Pattern service changes, this Pattern may not be applicable to this scenario or need to be corrected. Anyone can also discover and summarize the new Pattern.

Why Design Pattern?

The main advantages of designing Pattern are as follows:

• Reduce Design costs-each Design Pattern is the best practice for solving a common problem Design problem. Therefore, for the same problem, we do not need to repeat the Design, but only need to reuse it.
• Reduce Design risks-compared with the plain Design without implementation proof, Design Pattern is the best practice that has been proved by our predecessors, which is undoubtedly less risky.
• Reduce the cost of discussion and communication-for Design exchanges between software Design experts, if everyone understands the same Design Pattern, there is no need to provide too much Design details, therefore, communication costs are greatly reduced.

Does Design Pattern affect performance?

To some extent, we can say "yes ". Compared with the direct and simple implementation, Design Pattern often introduces some additional layers to gain certain flexibility. In part, it is objective to occupy more resources, or affect some performance.

However, we cannot look at the problem in isolation. Aside from applications with extremely high performance requirements, the performance loss introduced by Design Pattern in some aspects is often not unacceptable, and other benefits should also be taken into account; A wrong or inflexible design is more likely to cause overall program defects and bottlenecks, and often the cost of remediation is much higher.

Is Design Pattern insufficient for specific language descriptions?

To judge this proposition, we need to see whether "Design Pattern" is generic or special. If it is specific, since Design Pattern only refers to some reusable solution templates, for some programming practices that come from specific languages, of course, this proposition cannot be made true. For example, Core J2EE Patterns.

 

However, for Design Pattern that does not come from a specific language, such as GoF, the Design Pattern of object-oriented Design focuses on the basic principles and restrictions of object-oriented Design, it has nothing to do with a specific language. How can we make up for the lack of specific language description capabilities?