目录
C++ 设计模式——设计模式总结
设计模式是软件设计中常见问题的典型解决方案。它们是经过反复验证的、可重用的代码设计经验，用于解决在特定情境下反复出现的软件设计问题。
1. 面向对象程序设计的几个原则
- 开放封闭原则 (OCP - Open-Closed Principle)：软件实体应当对扩展开放，对修改封闭。这意味着一个实体允许其行为扩展，而无需修改其源代码。
- 依赖倒置原则 (DIP - Dependency Inversion Principle)：高层模块不应依赖低层模块，两者应依赖其抽象；抽象不应依赖细节，细节应依赖抽象。
- 组合复用原则 (CRP - Composite Reuse Principle)：尽量使用对象组合，而不是继承来达到复用的目的。
- 迪米特法则(LoD - Law of Demeter)/得墨忒法则/最少知识原则(LKP - Least Knowledge Principle)：一个对象应该对其他对象有尽可能少的了解。
- 单一职责原则 (SRP - Single Responsibility Principle)：一个类应该仅有一个引起它变化的原因。
- 里氏替换原则 (LSP - Liskov Substitution Principle)：子类型必须能够替换掉它们的父类型。
2. 设计模式的分类
- 创建型模式——关注对象的创建，把对象的创建和使用分离。创建型模式包括如下设计模式：简单工厂、工厂方法、抽象工厂、原型、建造者、单例。
- 结构型模式——关注对象之间的关系，研究如何组合各种对象以获得更灵活的结构并达到简化设计的目的。结构型设计模式包括如下设计模式：装饰、外观、组合、享元、代理、适配器、桥接。
- 行为型模式——关注对象的行为或交互，描述一组对象应如何协作完成一个整体任务。行为型模式包括如下设计模式：模板方法、策略、观察者、命令、迭代器、状态、中介者、备忘录、职责链、访问者、解释器。
3. 设计模式的定义
3.1 创建型设计模式的定义
- 简单工厂：定义一个工厂类，该类的成员函数可以根据不同参数创建并返回不同的类对象，被创建的对象所属的类一般都具有相同的父类。调用者无须关心创建对象的细节。
- 工厂方法：定义一个用于创建对象的接口，但由子类决定要实例化的类是哪一个该模式使得某个类的实例化延迟到子类。
- 抽象工厂：提供一个接口，让该接口负责创建一系列相关或者相互依赖的对象，而无须为它们指定具体的类。
- 原型：用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。
- 建造者：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
- 单例：保证一个类仅有一个实例存在，同时提供能对该实例访问的全局方法。
3.2 结构型设计模式的定义
- 装饰：动态地给一个对象添加一些额外的职责。就增加功能来说，该模式相比生成子类更加灵活。
- 外观：提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
- 组合：将一组对象组织成树形结构以表示“部分-整体”的层次结构。使得用户对单个对象和组合对象的操作/使用/处理具有一致性。
- 享元：运用共享技术有效地支持大量细粒度的对象(的复用)。
- 代理：为其他对象提供一种代理以控制对这个对象的访问。
- 适配器：将一个类的接口转换成客户希望的另外一个接口。该模式使得原本接口不兼容而不能一起工作的类可以一起工作。
- 桥接：将抽象部分与它的实现部分分离，使它们都可以独立地变化和扩展。
3.3 行为型设计模式的定义
- 模板方法：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中去实现，从而达到在整体稳定的情况下产生一些变化的目的。
- 策略：定义一系列算法类，将每个算法封装起来，让它们可以相互替换。换句话说策略模式通常把一系列算法封装到一系列具体策略类中，作为抽象策略类的子类然后根据实际需要使用这些子类。
- 观察者：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会自动得到通知。
- 命令：将一个请求或者命令封装为一个对象，以便这些请求可以以对象的方式通过参数进行传递，对象化了的请求还可以排队执行或者根据需要将这些请求录入日志供查看和排错，以及支持请求执行后的可撤销操作。
- 迭代器：提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。
- 状态：允许一个对象在其内部状态改变时改变它的行为，让对象看起来似乎修改了它的类。
- 中介者：用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，从而使耦合松散，而且可以独立地改变它们之间的交互。
- 备忘录：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可以将该对象恢复到原先保存的状态。
- 职责链：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它(请求)为止。
- 访问者：提供一个作用于某对象结构中的各元素的操作表示，使可以在不改变各元素类的前提下定义作用于这些元素的新操作。
- 解释器：定义一个语言的文法，并建立一个解释器解释该语言中的句子。
4. 重要提示
- 当系统的设计不需要预留任何弹性时，就不需要使用模式。
- 模式会带来复杂性和降低程序运行效率，除非必要，否则不要着急使用模式从而引入这种复杂性。
- 虽然可以发明自己的设计模式，但人们见到的大多数模式都是现有设计模式的变种而不是新模式。
- 设计模式并不能解决软件开发中的所有问题，是否使用设计模式要具体情况具体分析，要进行权衡。
- 许多设计模式的UML图看起来很类似，我们更应该关注的是某个模式专注于解决什么样的问题。
- 仅对程序中呈现出频繁变化的那些部分做出抽象，拒绝不成熟的抽象和抽象本身一样重要。
- 不写代码的架构师是值得怀疑的架构师。
- 测试工程师不是发现问题的机器，把明知道有缺陷的代码发送给测试工程师是非常不专业的。发布软件时，应该确保测试工程师找不到问题。