# 设计模式

**Repository Path**: daylight-star/design-patterns

## Basic Information

- **Project Name**: 设计模式
- **Description**: 基于C++的设计模式的学习，包含实例代码 + 个人理解
- **Primary Language**: C++
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2023-12-16
- **Last Updated**: 2024-01-31

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# C++设计模式

# 如何解决复杂性

- 分解
  - 人们面对复杂性有一个常见的做法：即**分而治之**，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。
- 抽象
  - 更高层次来讲，人们处理复杂性有一个通用的技术，即抽象。由于不能掌握全部的复杂对象，我们选择忽视它的非本质细节，而去**处理泛化和理想化**了的对象模型。

# 什么是设计模式

“**每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动**”。 ——Christopher Alexander

个人理解：设计模式面向的使用对象是：程序员，它帮助程序员如何去规范的编写有**规矩**的代码，这个**规矩**可以是很多，例如如何去设计、实例、调用一个类、也可以是如何去设计一个接口，这样的规矩是给**程序员本人或未来的其它人**设定，它可以帮助更好的**维护、扩展、阅读**代码。

当然偶尔的不符合设计模式的原则也是存在的，毕竟这是给人去更好的漫游、写出更优雅的代码，编译器自己能跑是无所谓的。

# 设计模式分类

设计模式是一些被广泛应用于软件开发的经验总结和最佳实践。**根据设计模式的目的和使用方式**，它们可以被分为以下几类：

- **创建型模式（Creational Patterns）**：这些模式关注如何创建对象，以达到最佳的灵活性和可重用性。其中包括单例模式、工厂模式、抽象工厂模式、建造者模式和原型模式等。
- **结构型模式（Structural Patterns）**：这些模式关注如何通过对象和类之间的组合来形成更大的结构，以便更好地实现系统的功能。其中包括适配器模式、桥接模式、组合模式、装饰器模式、外观模式、享元模式和代理模式等。
- **行为型模式（Behavioral Patterns）**：这些模式关注对象和类之间的通信方式，以便更好地管理算法、职责和流程。其中包括责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式和访问者模式等。
- **并发型模式（Concurrency Patterns）**：这些模式关注如何处理并发任务和多线程应用程序中的问题，以便更好地实现可伸缩性和可靠性。其中包括活动对象模式、管道和过滤器模式、保护性暂停模式、读写锁模式、信号量模式、单例模式等。

# 设计模式原则

Ps:基于程序员更好的去**维护、扩展、阅读**代码前人总结了以下八个原则。

1. 依赖倒置原则（DIP）

- 高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定) 。
- 抽象(稳定)不应该依赖于实现细节(变化) ，实现细节应该依赖于抽象(稳定)。


2. 开放封闭原则（OCP）

- 对扩展开放，对更改封闭。
- 类模块应该是可扩展的，但是不可修改。

3. 单一职责原则（SRP）

- 一个类应该仅有一个引起它变化的原因。
- 变化的方向隐含着类的责任。

4. Liskov 替换原则（LSP）

- 子类必须能够替换它们的基类(IS-A)。
- 继承表达类型抽象。

5. 接口隔离原则（ISP）

- 不应该强迫客户程序依赖它们不用的方法。
- 接口应该小而完备。

6. 优先使用对象组合，而不是类继承

- 类继承通常为“白箱复用”，对象组合通常为“黑箱复用” 。
- 继承在某种程度上破坏了封装性，子类父类耦合度高。
- 而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。

7. 封装变化点

- 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。

8. 针对接口编程，而不是针对实现编程

- 不将变量类型声明为某个特定的具体类，而是声明为某个接口。
- 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
- 减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案。