【C++】设计模式

设计模式的种类

设计模式一般可以分为三大类，每类又包含若干具体的设计模式：

1. 创建型模式（Creational Patterns）

创建型模式关注于对象的创建机制，试图将对象的创建、组合和表示分离。通过这种方式，系统可以独立于如何创建、组合和表示这些对象。

简单工厂（Simple Factory）：不是严格意义上的设计模式，但经常与工厂方法模式一起讨论。它不使用继承或接口，而是使用一个函数或静态方法来创建对象。

工厂方法（Factory Method）：定义了一个创建对象的接口，但由子类决定实例化哪一个类。工厂方法让类的实例化推迟到子类。

抽象工厂（Abstract Factory）：提供了一种创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

单例（Singleton）：确保一个类只有一个实例，并提供一个全局访问点。

建造者（Builder）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

原型（Prototype）：用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。

2. 结构型模式（Structural Patterns）

结构型模式处理类或对象的组合，描述了如何将对象或类组合成更大的结构，同时保持结构的灵活性和效率。

适配器（Adapter）：将一个类的接口转换成客户希望的另一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

桥接（Bridge）：将一个事物的抽象部分与它的实现部分分离，使它们都可以独立地变化。

组合（Composite）：将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。

装饰器（Decorator）：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。

外观（Facade）：为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

享元（Flyweight）：运用共享技术有效地支持大量细粒度的对象。

代理（Proxy）：为其他对象提供一种代理以控制对这个对象的访问。

复用与优化：HopeView与HopeFarm内核实践-CSDN博客

3. 行为型模式（Behavioral Patterns）

行为型模式专注于对象之间的责任分配和通信，描述了类或对象用于在运行时完成任务的方式。

责任链（Chain of Responsibility）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

命令（Command）：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

解释器（Interpreter）：给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。

迭代器（Iterator）：提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。

中介者（Mediator）：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

备忘录（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

观察者（Observer）：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都将得到通知并自动更新。

状态（State）：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。

策略（Strategy）：定义一系列算法，把它们一个个封装起来，并且使它们可以互相替换。本模式使得算法的变化独立于使用它的客户。

模板方法（Template Method）：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下重定义算法的某些特定步骤。

访问者（Visitor）：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

理解并正确应用这些模式可以帮助编写更清晰、灵活和可维护的代码。

在软件开发中，某些设计模式比其他模式更常用，这取决于具体的编程环境、项目需求以及团队的偏好。以下是一些最常见和广泛使用的设计模式：

### 创建型模式

1. **单例（Singleton）**
   - 确保一个类只有一个实例，并提供一个全局访问点。
   - **应用场景**：配置管理器、日志记录器等需要唯一实例的服务。

2. **工厂方法（Factory Method）**
   - 定义了一个创建对象的接口，但由子类决定实例化哪一个类。
   - **应用场景**：当一个类不知道它所必须创建的对象的类的时候，或者希望将对象的创建委托给子类时。

3. **抽象工厂（Abstract Factory）**
   - 提供了一种创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
   - **应用场景**：跨平台UI组件库，不同主题的界面元素创建等。

4. **建造者（Builder）**
   - 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
   - **应用场景**：复杂的对象创建，如大型数据结构或配置文件生成等。

5. **原型（Prototype）**
   - 用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。
   - **应用场景**：当创建成本高或复杂时，通过克隆已有对象来快速创建新对象。

### 结构型模式

1. **适配器（Adapter）**
   - 使原本由于接口不兼容而不能一起工作的那些类可以一起工作。
   - **应用场景**：对接旧系统或第三方库，API包装等。

2. **装饰器（Decorator）**
   - 动态地给一个对象添加一些额外的职责，相比生成子类更为灵活。
   - **应用场景**：GUI控件、流处理、权限验证等。

3. **代理（Proxy）**
   - 为其他对象提供一种代理以控制对这个对象的访问。
   - **应用场景**：远程服务调用、缓存、延迟加载等。

4. **外观（Facade）**
   - 为子系统中的一组接口提供一个一致的界面，简化了高层模块对子系统的使用。
   - **应用场景**：简化复杂库或框架的使用，提供统一的API。

### 行为型模式

1. **观察者（Observer）**
   - 定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都将得到通知并自动更新。
   - **应用场景**：事件驱动系统、订阅-发布模型等。

2. **策略（Strategy）**
   - 定义一系列算法，把它们一个个封装起来，并且使它们可以互相替换。
   - **应用场景**：算法选择、规则引擎等。

3. **模板方法（Template Method）**
   - 定义一个操作中的算法骨架，而将一些步骤延迟到子类中。
   - **应用场景**：框架开发，定义固定流程但允许定制具体实现。

4. **命令（Command）**
   - 将请求封装成对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
   - **应用场景**：插件式架构、宏命令、事务处理等。

这些模式之所以被广泛使用，是因为它们解决了许多常见的软件设计问题，并提供了良好的代码组织和扩展性。然而，选择哪个模式取决于具体的上下文和需求。在实际应用中，开发者可能会根据项目的特定要求来选择最合适的设计模式，甚至组合使用多种模式。

常用模式

以下是几种最常用的设计模式，这些模式在实际开发中频繁出现

创建型模式

单例（Singleton）
为什么常用：确保一个类只有一个实例，并提供全局访问点。非常适合用于管理连接池、配置管理等需要唯一实例的场景。

工厂方法（Factory Method）
为什么常用：允许子类决定创建哪一个产品对象，增加了灵活性和扩展性。适用于需要根据条件创建不同类型的对象的情况。

https://blog.csdn.net/bandaoyu/article/details/107423063

建造者（Builder）
为什么常用：当需要创建复杂对象时，使用建造者模式可以将构造过程与表示分离，使得同样的构建过程可以创建不同的表示。常用于GUI组件、大型数据结构的构建等。

https://blog.csdn.net/bandaoyu/article/details/83511946

结构型模式

适配器（Adapter）
为什么常用：使原本由于接口不兼容而不能一起工作的那些类可以一起工作。非常适合处理遗留代码或第三方库的集成问题。

装饰器（Decorator）
为什么常用：动态地给一个对象添加一些额外的职责，相比生成子类更为灵活。非常适合于需要在运行时动态改变对象行为的场景，如权限控制、日志记录等。

外观（Facade）
为什么常用：为复杂的子系统提供一个简化的接口。非常适合简化对复杂库或框架的使用，降低学习曲线。

https://blog.csdn.net/bandaoyu/article/details/83418368

行为型模式

观察者（Observer）
为什么常用：定义了一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都将得到通知并自动更新。非常适合事件驱动系统和订阅-发布模型。

策略（Strategy）
为什么常用：允许算法独立于使用它的客户端变化。非常适合需要在运行时选择不同算法或行为的场景。

命令（Command）
为什么常用：将请求封装成对象，从而可以参数化客户、队列或记录请求，并支持可撤销操作。非常适合插件式架构和宏命令的实现。

原文地址：https://blog.csdn.net/bandaoyu/article/details/144723588

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！