According to the table of contents of the novice tutorial, let's first take a look at the creation mode. Research on creational patterns:

The various specific patterns under the creational pattern are explained below.

Let’s look at the example first: Factory pattern.

Users of a certain function only deal with the interface and do not care about how to implement it. In this case, there must be an interface class, and the user uses the interface; the function provider inherits and implements the interface. This takes advantage of the polymorphic nature of C++.

Since the user only cares about the interface, there is no need to give the subclass directly to the user, and there is no need for the user to directly new the subclass in the code. If you do this, unnecessary information will be exposed to the user and increase the coupling of information. Just imagine, if the user has new subclasses in many places, if these places need to be modified, how to change them? It can only be modified one place at a time. After the modification, it still needs to be compiled, making maintenance extremely difficult.

The factory mode means that for a certain functional interface, we need to create a new factory class. This factory class encapsulates the interface subclass name and the creation process of the interface subclass, and only returns an interface pointer to the interface. of users. The implementation class of the interface is completely transparent to users and highly decoupled. This makes it easy to switch the specific implementation of the interface without affecting users of upper-layer functions. Take a car as an example. No matter what the process of producing a car is in a factory, as long as it is a car, its driving method (human-machine interface) is similar.

Obviously, the factory pattern adds an encapsulation layer between the user and the implementer, which confirms a famous saying in the computer industry:

A typical example is: in Qt The database module uses the factory pattern to encapsulate the underlying implementation of the database. While keeping the database user interface unchanged, seamless switching of database types can be achieved by replacing the database driver.

Use it when the demand tends to be stable. When the demand is unstable, do not over-design, otherwise the design will be easily overturned and your efforts will be in vain.

From the essence of the design pattern, the factory pattern:

Let’s look at the example first: Abstract Factory Pattern.

As can be seen from the previous factory pattern, all "factories" have one thing in common: each factory provides functions for creating objects. Since all factories implement the same type of functionality, we can abstract a public interface (virtual base class) for the factory. This interface defines the function of creating factory subclasses. Does this scene seem familiar? Yes, factories and factory functional interfaces constitute scenarios for using the factory pattern. That is, the factory itself also applies to the factory pattern. To design a factory using the factory pattern, you must write a factory for the production factory. The return value of a production factory is the abstract interface class of the factory, so this design pattern is called "Abstract Factory Pattern". In fact, I think it is easier to understand this design pattern as "Factory Factory Pattern".

If there is only one factory, do not use the abstract factory pattern. Only use the abstract factory pattern when there are many factories.

When demand is unstable, don’t over-design, as everything may be overturned. For small projects, there is no need to overly pursue the use of design patterns. It is best for the architecture code to only account for a small part of the entire project code, otherwise the priorities will be reversed and cause trouble for yourself. For large projects, when the demand is relatively stable, in order to improve maintainability and scalability, you can consider using design patterns. In addition, the abstract factory pattern is difficult to understand. You need to consider whether the code you design can be read by others. Ease of understanding is also an aspect that needs to be considered.

So, from the essence of the design pattern,

Let’s look at the example first: Singleton pattern.

The above examples all allow a class to be created multiple times. If we want to restrict a class to be created only once, that is, to have only one globally accessible instance (like global variables in C language), such as an application object, there should be only one application object per application. How should I write code at this time?

The answer is encapsulation.

Hide information that you don’t want to be exposed, and expose information that must be exposed. The singleton mode sets the constructor of the class to private access rights, restricting external instances from being created through new. Instance pointers can only be obtained through specific interfaces. It should be mentioned that multi-thread safety issues need to be considered when encapsulating.

When a class needs to have multiple instances, the singleton pattern is not used.

From the essence of the design pattern,

For specific examples and writing methods, you can refer to the builder pattern in the novice tutorial.

A typical usage scenario of the builder pattern is the set meal matching model of a fast food restaurant. The set meal is composed of several individual meals. A single meal is composed of different raw materials. In the application scenario of this layer-by-layer combination of tree-shaped object relationships, in order to create the top-level object, it is necessary to first create the underlying objects layer by layer, and gradually move upward until the root object is constructed. In this scenario, inheritance can be used to associate objects of the same type, and composition can be used to combine objects of different types. Combination is to save different objects in a piece of memory and use them as a whole.

It is highly discouraged to use inheritance entirely to solve such problems. There is a principle in design pattern theory: "use inheritance less and use composition more". Because inheritance is a strong coupling, composition is a loose coupling. Coupling is not conducive to adapting to changes in requirements and is a time bomb in the project.

From the nature of design patterns,

One design pattern that is not mentioned in the novice tutorial is the combination pattern. For specific content, please refer to: Section 4: Detailed explanation of combination mode and builder mode.

Let me briefly explain here that the combination mode is similar to the builder mode, and also follows the tree object relationship structure. Compared to the builder pattern, the difference is that the child object and the parent object have the same type. So it can be said that the composition pattern is a simple builder pattern.

For specific usage scenarios and examples, see Prototype Pattern.

Prototype mode may not be used much in actual use. Describe its characteristics in one sentence:

This kind of cloning is an in-memory copying behavior. It is fast, can make full use of the cached data of existing objects, and has high performance. The cloned object has the same properties and behaviors as the original object, and can be used to help the original object handle some transactions. To use a word from anime to describe it, "shadow clone" couldn't be more appropriate.

From the essence of design patterns,

In the next article, we will introduce structural patterns.