This article has participated in the Denver Nuggets Creators Camp 3 “More Productive writing” track, see details: Digg project | creators Camp 3 ongoing, “write” personal impact.

Preface:

As a siege lion, the word “design pattern” should be familiar. So, have you settled down to systematically learn it? This blog series describes the implementation of object-oriented design patterns. The name — C# design pattern is given because the example I use in this article is done in C#. Of course, you can read this series of articles from the perspective of any object-oriented language you are familiar with. I will help you master each design pattern in terms of its intent, problem, solution, and specific case. If you happen to want to learn design patterns systematically, and you happen to read this article, then please learn with me.


First, why learn design patterns?

Good design patterns are designed to adapt to change and improve reuse. If your program doesn’t change, you can write well without a design pattern. But so far I’ve worked on projects that didn’t need to change, sometimes even halfway through feature development when the requirements changed. Of course, it’s more about the variation that comes with subsequent feature expansions, which can be mitigated by design patterns.

Design pattern is a word I heard when I first started working on the project, but it was a long time before I learned it (two or three years before I started). At that time, when I heard who used design patterns where, I felt that this person was very powerful.

When I started learning about design patterns, I realized that I had already used some design patterns (e.g., singleton patterns) without knowing it. So maybe design patterns aren’t as esoteric as we think, and maybe they don’t require years of programming, so why not take the time to systematically learn them?


Second, what are design patterns?

Design patterns are typical solutions to common problems in software design. They are like prefabricated blueprints that can be adapted to meet requirements and can be used to solve recurring design problems in your code.

Design patterns can help designers complete system designs faster and better, and also make it easier to reuse successful designs and architectures.

Design patterns define a way for you and your team to work together better. For example, if you say this place needs to use singletons, everyone will know how to do it. You don’t have to explain what singletons are.

Design patterns differ from algorithms: because both are conceptually solutions to known problems, they can be confused. It can be understood that the algorithm is a concrete implementation step to implement the solution, and the pattern is a higher level description of the solution.


Three, how to describe the design pattern?

Most schemas have formal descriptions so they can be used in different situations. The description of a pattern usually includes the following sections:

  • Intention section: Briefly describe the problem and solution. What does intent tell us about this design pattern? What is its rationale? What specific design problem is it used to solve?
  • The motivation section further explains the problem and shows how patterns can provide a solution. Motivation is used to describe a design problem and a particular scenario of how to solve the problem using classes and objects in the pattern. This scenario will help you understand a more abstract description of the pattern.
  • Structural sections: Show each part of the pattern and the relationships between them.
  • Effects: How does the pattern support its goals, the effects of using the design pattern, and the trade-offs required? What parts of the system architecture can be changed independently?
  • Implementation: You need to know some tips, technical tips and pitfalls to avoid when implementing patterns, and whether certain language-specific implementations exist.

Four, what are the types of design patterns?

Different design patterns vary in complexity, detail level and application scope in the whole system. All patterns can be divided into three main patterns categories based on their intent or purpose:

  1. Creation pattern: Provides a mechanism to create objects, increasing the flexibility and reusability of existing code.

The creation class pattern deferred part of the creation of an object to a subclass, while the creation object pattern deferred it to another object. 2. Structural pattern: Describes how to assemble objects and classes into a larger structure while keeping the structure flexible and efficient. The structural class pattern uses inheritance mechanisms to combine classes, while the structural object pattern describes how objects are assembled. 3. Behavior pattern: Responsible for efficient communication between objects and assignment of responsibilities. The behavior tree pattern uses inheritance to describe algorithms and control flows, while the behavior tree object pattern describes how a group of objects can collaborate to accomplish things that a single object cannot

23 design modes:

Creation pattern Structural mode Behavioral pattern
This type of pattern provides a mechanism for creating objects that can improve the flexibility and reusability of existing code. This type of pattern describes how to assemble objects and classes into a larger structure while keeping the structure flexible and efficient. This type of pattern is responsible for effective communication between objects and delegation of responsibilities.
Singleton Singleton

Factory Method

Abstract Factory

The generator Builder

Prototype Prototype
The Adapter Adapter

Bridge Bridge,

Combination of the Composite

Decorate the Decorator

Appearance of the Facade

The Proxy agent

The Flyweight Flyweight

Strategy is the Strategy
The Chain of Responsibility

Command to the Command

The Iterator Iterator

Mediator Mediator

Rzhetsky memo

The Observer the Observer

State of the State

Template Method


Five, the relationship between design patterns?

Some design patterns are often used together, and the diagram below shows a graphical illustration of the pattern relationships.


Learn the four states of design patterns:

  1. I don’t know how to use design patterns. I can’t imagine how bad the code is.
  2. After learning several patterns, I was very happy, so I thought about using the patterns I had learned, so I often misused the patterns without realizing it.
  3. When learning the complete part of the model, I feel that many models are extremely similar, and can not distinguish the differences between the models. I am confused, but I know the harm of misuse and hesitate when applying them.
  4. Flexible application of patterns, even without the application of a specific pattern can be very good design

Recommended books: Design Patterns: The Foundations of Reusable Object-oriented Software, GoF, Big Talk Design Patterns, Cheng Jie, Agile Software Development: Principles, Patterns, and Practices, RobertC. Martin, Refactoring: Improving Existing Code Design, Martin Fowler