reference from (https://blog.csdn.net/QIJINGBO123/article/details/108539158)(纯搬运)
六大设计原则
1.单一职责原则
类的职责单一，对外提供一个功能，函数也支持；
2.里氏替换原则
任何抽象类的出现都可以用他的实现类进行替换。
3.依赖倒置原则
依赖于抽象，不要依赖具体实现，也就是针对接口编程
4.接口隔离原则
一个接口对外应该只提供一种对外功能，不应该把所有操作都封装到一个接口里。
5.开闭原则
对扩展开放，对修改关闭；
6.迪米特原则（最少知识原则）
对象之间应该尽可能降低耦合度，可以通过提供一个
统一的接口来实现对象之间的交互
常见的单例模式
1.单例模式
单例模式，顾名思义，就是一个类只能有一个对象。
实现方式
1）构造函数或者拷贝构造函数私有化；
2）共有的静态变量和静态函数；
单例模式分为懒汉模式和饿汉模式。懒汉模式是在第一次用到类实例时才会实例化对象，而饿汉模式在定义时就创建了对象。其中，在多线程情况下，懒汉模式需要考虑安全问题(在多线程环境中，如果懒汉模式没有进行线程安全的处理，可能会出现多个线程同时调用getInstance方法，导致多个实例被创建的问题。)，而饿汉模式不需要。
懒汉模式
class Singleton
{
private:
Singleton(); // 构造函数私有化
Singleton(const Singleton& other); // 拷贝构造函数私有化
public:
static Singleton* getInstance();// 静态成员函数
static Singleton* m_instance;// 静态变量
};
2.策略模式
策略模式（Strategy Pattern）是一种设计模式，它定义了一系列算法，将每个算法封装起来，并且使它们可以相互替换。策略模式让算法的变化独立于使用算法的客户端。
在策略模式中，通常有三个角色：
1.策略接口（Strategy Interface）：定义了一组算法的接口，这些算法可以被相互替换。
2.具体策略类（Concrete Strategy）：实现了策略接口，提供了具体的算法实现。
3.上下文类（Context）：持有一个策略接口的引用，它可以将具体的算法委托给策略接口来执行。
策略模式的优点在于，它可以让客户端根据不同的需求，选择不同的算法来执行，而不需要修改客户端的代码。另外，策略模式还可以让算法的实现和使用解耦，方便维护和扩展。
举个例子，假设有一个商场正在进行促销活动，针对不同的客户群体，可以采用不同的促销策略，如打折、赠品等。这时候，可以使用策略模式来实现不同的促销策略，将每个促销策略封装成一个具体的策略类，然后在商场的促销活动中根据不同的客户群体选择不同的促销策略。这样，即使商场需要改变促销策略，也只需要新增或修改相应的具体策略类，而不需要修改商场的促销活动代码。
+------------------+ +---------------+
| Context | | Strategy |
+------------------+ +---------------+
| - strategy: Strategy | <---| + algorithm() |
+------------------+ +---------------+
| + setStrategy() | ^ |
| + execute() | |
+------------------+ |
|
+----------------+----------------+
| | |
+---------------+ +-----------------+ +------------------+
| ConcreteStrategyA | ConcreteStrategyB | ConcreteStrategyC |
+---------------+ +-----------------+ +------------------+
| + algorithm() | | + algorithm() | | + algorithm() |
+---------------+ +-----------------+ +------------------+
3.外观模式【肯德基套餐模式】
外观模式（Facade Pattern）是一种结构型设计模式，它提供了一个简化接口，用于访问系统中的一组复杂子系统。外观模式通过将子系统的复杂性隐藏在一个简单的接口背后，使得客户端能够更方便地使用系统，并且不需要了解子系统的内部实现细节。
在外观模式中，通常有三个角色：
1.外观（Facade）：提供了一个简单的接口，用于访问系统中的一组复杂子系统。
2.子系统（Subsystem）：包含了一组复杂的类或对象，实现了系统的各种功能。
3.客户端（Client）：使用外观来简化系统的接口，并且不需要了解子系统的内部实现细节。
外观模式的核心思想是将子系统的复杂性封装在一个外观对象中，提供一个简单的接口给客户端使用。这样，客户端只需要和外观对象打交道，就可以完成复杂的操作。外观对象会将请求转发给子系统进行处理，从而实现系统的各种功能。
+-----------+ +-----------------+
| Client | | Facade |
+-----------+ +-----------------+
| +run() | <---| - subsystem1() |
+-----------+ | - subsystem2() |
| - subsystem3() |
+-----------------+
| + operation() |
+-----------------+
+----------------+----------------+----------------+
| | | |
+--------------+ +---------------+ +---------------+
| Subsystem1 | | Subsystem2 | | Subsystem3 |
+--------------+ +---------------+ +---------------+
| + operation1()| | + operation2()| | + operation3()|
+--------------+ +---------------+ +---------------+
4.简单工厂模式
简单工厂模式（Simple Factory Pattern）是一种创建型设计模式，它定义了一个简单的工厂类，该类可以根据给定的参数来创建不同的对象。
简单工厂模式由三个主要角色组成：
1.工厂类（Factory）：工厂类负责创建对象。通常情况下，它是一个静态方法，接受一个参数，根据参数创建对应的对象并返回。
2.抽象产品类（Product）：抽象产品类定义了产品的通用接口和属性。
3.具体产品类（Concrete Product）：具体产品类实现了抽象产品类的接口，并且定义了自己的属性和方法。
简单工厂模式的核心思想是将对象的创建过程封装在工厂类中，客户端只需要提供参数，就可以获得所需的对象。这样，客户端和具体产品类之间的耦合度降低，同时也降低了代码的复杂度和重复性。
+-----------+ +-----------------+
| Client | | Factory |
+-----------+ +-----------------+
| +run() | <---| + createProduct()|
+-----------+ +-----------------+
| |
| +Product |
+-----------------+
| |
+----------------+----------------+
| | |
+--------------+ +---------------+ +---------------+
| Product1 | | Product2 | | Product3 |
+--------------+ +---------------+ +---------------+
| +operation() | | +operation() | | +operation() |
+--------------+ +---------------+ +---------------+
5.工厂模式
工厂模式=简单工厂模式+开闭原则
缺点
类的个数成倍增加，导致类越来越多，代码维护量加大。
6.抽象工厂模式
7.观察者模式
观察者模式（Observer Pattern）是一种常见的设计模式，也被称为发布-订阅模式（Publish-Subscribe Pattern）。观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，当主题对象发生变化时，它的所有观察者都会收到通知并自动更新。
抽象主题（Subject）：定义了观察者需要观察的主题对象的接口，包括添加、删除和通知观察者的方法。
具体主题（ConcreteSubject）：实现了抽象主题接口，并维护了一个观察者列表，可以添加、删除和通知观察者。
抽象观察者（Observer）：定义了一个更新接口，用于在主题发生变化时更新自身。
具体观察者（ConcreteObserver）：实现了抽象观察者接口，并维护了一个指向具体主题对象的引用，以便在需要时接收主题的通知。
在这个类图中，WeatherData 是具体主题类，实现了主题接口 Subject 中定义的注册观察者、移除观察者、通知观察者等方法。Observer 是抽象观察者类，定义了更新气象数据的方法 update()。CurrentConditionsDisplay 和 ForecastConditionsDisplay 是具体观察者类，分别实现了抽象观察者类中定义的更新方法，并实现了显示气象数据的方法 display()。
+----------------------+ +---------------+
| WeatherData | | Observer |
+----------------------+ +---------------+
| +registerObserver() | | +update() |
| +removeObserver() | +---------------+
| +notifyObservers() |
| +setMeasurements() |
+----------------------+
▲ ▲
| |
| |
+------------------+ +-----------------------+
| CurrentConditions| | ForecastConditions |
+------------------+ +-----------------------+
| +update() | | +update() |
| +display() | | +display() |
+------------------+ +-----------------------+