C + + must Know (three) design pattern

For anyone unfamiliar with design patterns, a brief overview of the field may leave the impression that design patterns are a big marketing scam, a simple programming technique, or just a plaything of computer scientists. While these impressions have a point, the design pattern is indeed an integral component of the professional C + + Programmer's Toolbox.

Design patterns are an architectural theme that is repeatedly discussed. It provides solutions to common design problems in specific contexts and describes the results of this solution. The design pattern is not simply a description of the technology, it is a named encapsulation of the design wisdom that is pooled from existing successful practices, and is written in the form of 窬 communication and reuse. Patterns are a matter of smooth communication between programmers.

From a practical point of view, the design pattern has two important attributes. First, they describe proven and successful design techniques that can be customized in a context-sensitive way to meet the requirements of new design situations. Second, and perhaps more importantly, when referring to a particular application, it includes not only the techniques used in it, but also the motivations for applying the pattern and the results achieved after the application.

This kind of thing is nothing new. Consider an analogy from the domain of algorithms. Consider the following declaration: "There is an unordered sequence that must be searched many times." Therefore, you want to sort it quickly and use a binary lookup to perform each lookup. "The ability to use the term" quick sort "and" binary lookup "is invaluable, not only in design, but also in communication with educated colleagues about the design. When I say "quick sort", my colleague knows that the sequence I'm sorting has a random access structure, and it's sort time complexity O (nlog2n), and that the elements in that sequence can be compared by a similar less-than-operator. When I said "binary lookup," my colleague knew that the sequence had been sorted, that the time complexity of the comparison operation performed by an element of interest was O (log2n), and that there was an appropriate operation to compare the elements in the sequence. The shared knowledge and standard vocabulary of the standard algorithms not only allow efficient recording of documents, but also allow for effective evaluation of the design proposals. For example, if I plan to perform this lookup and sequencing process on a one-way linked table structure, my colleagues will immediately laugh with complacency and point out that in this case I cannot use a quick sort and may not want to use a binary lookup.

Prior to the advent of design patterns, these advantages are not available in documenting, communicating, and efficiently commenting on object-oriented design. We are forced to describe our design at a low level, which is inefficient and imprecise. This is not to say that technology for complex object-oriented design does not yet exist, but that these technologies have not yet been used in a shared, generic term way for the entire programming community. The design pattern solves this problem, and we can now describe the object-oriented design as efficiently and without ambiguity as described in the algorithm design.

For example, when we see the bridge pattern being applied to a design, we know that at a simple mechanism level, the abstract data type implementation is separated into an interface class and an implementation class. In addition, we know that the reason for this is to strongly detach the interface from the implementation, so that changes to the implementation will not affect the user using the interface. We also know that this separation leads to runtime overhead, knowing how to lay out the source code for the abstract data type, and many other details. The name of the pattern is an efficient and unambiguous "handle" of many of the information and experiences of a technology, and careful and proper use of patterns and pattern terminology in design and documentation can make code and design more explicit.

Those rigorous pattern experts sometimes describe patterns in some form of literature that follows a formal structure. Several common variants are also in use, but either way, the following 4 essential parts are included:

First, the design pattern must have a name that is unambiguous. For example, the term "wrapper" (wrapper) is meaningless for design pattern naming because it is already widely used and has many different meanings. Using terms such as "wrapper" to name a design pattern can only lead to confusion and misunderstanding. The practice is: previously in the "wrapper" name of the design technology designated as "bridge" "strategy" "Façade" "Object Adapter" and some other pattern names. Using exact pattern names has the "obvious" advantage of using less precise names, just as the term "binary lookup" is more accurate than "lookup."

Second, the pattern description must define the problem that the pattern can solve. This description can be relatively broad or relatively narrow.

Again, the pattern describes the solution to describe the problem. Depending on the stated problem, the solution can be relatively advanced or relatively low-level, but in any case it should be versatile enough that it can be tailored to the different contexts in which the problem may occur.

Finally, the pattern description is to describe the consequences of applying the pattern to a context. How does the context change when the pattern is applied? Whether it's getting better or worse.

Does owning a pattern of knowledge turn a bad designer into a good designer? Well, it's time to give another analogy, and imagine you're forced to learn a painful math class, and its final exam is to prove a lot of theorems in a field. What if you can escape from this class? The most obvious way, of course, is to be a genius. It starts with the initial principle, and then studies the basic knowledge of the whole branch of mathematics, and finally proves those theorems. A more practical approach is to you remember and digest a large number of theorems in the field of mathematics and use any of the gifted mathematical abilities, inspirations, and good luck to choose the appropriate auxiliary theorems, and then glue them together with some sort of logic, thus eventually proving the new theorem. Yes, even for those "gifted in transit," This is an advantage, because it is easier to communicate with "mortals" by proving that they are more efficient based on ready-made theorems. Of course, familiarity with the auxiliary theorem does not guarantee that a poor student of mathematics will pass the exam, but such knowledge can at least enable it to understand the proofs given by others.

In the same way, from the original principle to the complex object-oriented design is also quite boring, and communicate with others the final design is difficult. A combination of design patterns is used to generate object-oriented design, similar to the use of auxiliary theorems in mathematics to prove a new theorem. Design patterns are often described as "micro-architecture", which can be combined with other schemas to generate a new schema. Of course, choosing the right pattern and effectively combining it also requires expert experience and talent endowment in design. However, once the design is complete, even your manager will be able to understand the complete design, as long as he has some knowledge of the necessary patterns.