C++ design pattern (1)

Introduction

  I learned all the design models in the past, but due to long periods of non-use, they will gradually be forgotten; therefore, I recently restarted learning programming design patterns; and I myself am engaged in C++ related development, and examples of C++ on the Internet Relatively few (mostly java), so these design patterns are implemented in C++ code.
  The design pattern is mainly a design idea proposed for object-oriented languages, which is mainly used to improve the reusability of the code, that is, when the requirements change, try to reduce the impact and make the least changes.
   Object-oriented has three characteristics: 1. Encapsulation, hiding the internal logic implementation; 2. Inheriting and reusing existing code; 3. Polymorphism, rewriting the behavior of the object to achieve multiple types of multiple behaviors.
   The six principles of object-oriented design patterns:
    1. The principle of dependency inversion: programming for interfaces depends on abstraction rather than specific implementation; that is, abstraction does not depend on implementation details, and implementation details depend on abstraction; thus combining static parts with Split the dynamic part, otherwise the static part will become the dynamic part.
    2. The principle of opening and closing: open for extension and close for modification. Business is constantly changing. When the program needs to be changed, upgraded or maintained, instead of directly modifying the program, it should use an extension method to flexibly apply abstraction, inheritance and polymorphism to enhance the scalability of the program.
    3. Single responsibility principle: a class only does one thing, a class has only one reason for its change, and the direction of its change implies the responsibility of the class.
    4. The Richter substitution principle: the subclass must be able to replace the parent class, and any reference to the parent class must be able to transparently use the objects of its subclass. The Richter replacement mainly relies on the two characteristics of inheritance and polymorphism.
    5. The principle of interface isolation: Minimize the interface, minimize the external interaction of a class's public functions, and expose only the externally needed methods.
    6. Least Knowing Principle: Also known as the Dimit Principle, it means that an object should have the least knowledge of other objects. That is, a class interacts with other classes as little as possible.

What is GoF

When it comes to design patterns, GoF must be inseparable:

GoF: Gang of Four, also known as the "Group of Four", namely: EErich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

  In 1994, these big cows co-authored and published a book called "Design Patterns: Elements of Reusable Object-Oriented Software" (ie: "Design Patterns"). The book first mentions the concept of design patterns in software development, elevating design patterns to a theoretical level, and standardizing them. The book mentions 23 basic design patterns. Today, in the development of reusable object-oriented software, new design patterns are still emerging.

Types of design patterns

Types of description
Creative Patterns (Creative Patterns) Mainly used to construct objects so that they can be separated from the real system
Structural patterns (Structural Patterns) Mainly used to form a large object structure between many different objects
Behavioral Patterns Mainly used to manage algorithms, relationships and responsibilities between objects

Creative Patterns (Creative Patterns)

  1. Singleton Pattern: Ensure that a class has only one instance and provide a global access point to access it.
  2. Abstract Factory Pattern (Abstract Factory Pattern): to create a series of related or interdependent objects interface, without specifying their specific classes.
  3. Builder Pattern: Separate the construction of a complex object from its representation, so that the same construction process can create different representations.
  4. Factory Method Pattern: Define an interface for creating objects and let subclasses decide which class to instantiate.
  5. Prototype Pattern: Use a prototype object to create a specified object, and create it by copying, which is equivalent to cloning.

Structural patterns (Structural Patterns)

  1. Adapter Pattern: Convert the interface of one class to another interface. The adapter can adapt the originally incompatible classes to work together.
  2. Bridge Pattern: Separate the abstract part from its realization part, allowing them to be changed independently.
  3. Decorator Pattern: dynamically add some extra responsibilities to an object. From an extension point of view, it is more flexible than subclassing.
  4. Composite Pattern: Combine objects into a tree structure to represent a "part-whole" hierarchical structure. It enables customers to have consistency in the use of single objects and composite objects.
  5. Facade Pattern: Provide a consistent interface for a group of interfaces in the subsystem. In this way, the loose coupling relationship between the subsystem and the client is realized; for the client, the components of the subsystem are shielded, the number of objects that the client needs to be processed is reduced, and the subsystem is easier to use.
  6. Flyweight Pattern: Use sharing technology to effectively support a large number of fine-grained objects.
  7. Proxy Pattern: Provide a proxy for the object to control access to the object.

Behavioral Patterns

  1. Template Method Pattern: Define the skeleton of an algorithm in operation, and delay some steps to subclasses. Template Method allows subclasses to redefine certain specific steps of an algorithm without changing the structure of an algorithm.
  2. Command Pattern: It is a data-driven design pattern. Encapsulate a request as an object so that you can parameterize customers with different requests.
  3. Iterator Pattern: Provides a way to sequentially access each element in an aggregate object without exposing the internal representation of the object.
  4. Observer Pattern: Define a one-to-many dependency relationship between objects so that when an object's state changes, all objects that depend on it are notified and automatically refreshed. When there is a one-to-many relationship between objects, the observer pattern is used.
  5. Mediator Pattern: Use a mediator object to encapsulate a series of object interactions. The intermediary makes the objects do not need to explicitly refer to each other, which loosens the coupling and can independently change the interaction between them.
  6. Memento Pattern: Under the premise of not destroying encapsulation, capture the internal state of an object and save this state outside the object. In this way, the object can be restored to its saved state later.
  7. Interpreter Pattern: Given a language, define a representation of its grammar, and define an interpreter that uses the representation to interpret sentences in the language.
  8. State Pattern:Allows an object to change its behavior when its internal state changes. The object seems to modify the class it belongs to.
  9. Strategy Pattern: Define a series of algorithms, encapsulate them one by one, and make them interchangeable. This mode allows the algorithm to change independently of the client using it.
  10. Chain of Responsibility Pattern: In order to remove the coupling between the sender and receiver of the request, multiple objects have the opportunity to process the request. Connect these objects into a chain and pass the request along this chain until an object handles it.
  11. Visitor Pattern (Visitor Pattern): Represents an operation that acts on each element in an object structure. It allows you to define new operations that act on these elements without changing their class.

  Note: The detailed description of each design mode will be filled in in the future. First, make an overall summary and understand each design mode together.

Guess you like

Origin blog.csdn.net/CFH1021/article/details/108885862