设计模式

参考资料

链接	说明
C++设计模式入门	b站优质课程-强烈推荐
设计模式	runoob教程
Cpp中的多态实现方式	使用多态指针/模板实现多态

本笔记基于C++设计模式入门和《设计模式 可复用面向对象软件的基础》

设计模式概述

面向对象设计原则

1. 依赖倒置原则(DIP)：

   • 高层次的代码（稳定）不应该依赖低层次的代码（变化）、抽象的代码不应该依赖具体的代码。

   • 抽象(稳定)不应该依赖于实现细节(变化)，实现细节应该依赖于抽象(稳定)。

   理解：实现隔离变化，即使得高层次的模块不依赖于底层模块的实现细节，从而使得高层次模块可以在不改变的情况下改变底层模块的实现。

2. 开放封闭原则(OCP)：

   • 对扩展开放，对修改封闭。

   • 类模块应该是可扩展的，但是不可修改。

   理解: 扩展:使得在不改变原有代码的情况下，通过扩展的方式来实现新的功能。

3. 单一职责原则(SRP)：

   • 一个类应该仅有一个变化的原因
   • 该变化隐含了它的职责，职责太多时会导致扩展时对代码东拉西扯，造成混乱。

   理解：功能隔离，使得一个类只负责一个功能，这样当功能发生变化时，只需要修改一个类即可。

4. 替换原则(LSP)：
   • 子类必须能够替换它的基类（IS-A）
   • 继承可以表达类型抽象。

   理解：继承，使得需要父类的地方可以使用子类来替代，从而使得代码更加灵活。

5. 接口隔离原则(ISP)
   • 接口应该小而完备
   • 不应强迫客户程序使用多余的方法

   理解：接口的设计更加精简，不应该包含多余的方法。即只在有必要的情况下才public暴露接口。

6. 优先使用对象组合，而不是类继承：
   • 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。
   • 继承在某种程度上破坏了封装性，子类父类之间的耦合性太高。
   • 而对象组合则只要求被组合对象具有良好的接口，耦合性更低。

   理解：对象组合，使得类之间的耦合性更低，更加灵活。

7. 封装变化点：
   • 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生影响，从而实现层次间的松耦合。
8. 针对接口编程，而不是针对实现编程。
   • 面向接口编程

使用设计模式的注意点

寻找变化点，在变化点处使用设计模式，把变化与稳定隔离开来。

运用设计模式，在稳定与变化间寻找隔离点。

不要先入为主地使用设计模式，没有一步到位的设计模式。要学会重构代码

不同的类做同一件事时使用接口，不同的类做同一件事但需要不同效果时使用委托

如何重构代码/重构关键技法:

静态 -> 动态

早绑定 -> 晚绑定

继承 -> 组合

编译时依赖 -> 运行时依赖

紧耦合 -> 松耦合

设计模式分类

从封装变化角度对设计模式进行分类：

1. 组件协作：
   • Template Method
   • Strategy
   • Observer/Event
2. 单一职责：
   • Decorator
   • Bridge
3. 对象创建：
   • Factory Method
   • Abstract Factory
   • Prototype
   • Builder
4. 对象性能：
   • Singleton
   • Flyweight
5. 接口隔离：
   • Facade
   • Proxy
   • Mediator
   • Adapter
6. 状态变化：
   • Memento
   • State
7. 数据结构：
   • Composite
   • Iterator
   • Chain of Responsibility
8. 行为变化：
   • Command
   • Visitor
9. 领域规则：
   • Interpreter

设计模式间关系：

类图说明：

组件协作设计模式

组件协作模式通过晚绑定，动态组合的方式实现松耦合，从而实现组件之间的协作。

模板方法模式/Template Method

体现了晚绑定的设计思路(虚函数)

描述：定义一个操作中的算法的骨架(稳定)，而将一些步骤延迟(变化)到子类中。Template Method使得子类可以不改变（复用）一个算法的结构即可重定义（override重写）该算法的某些特定步骤。

策略模式/Strategy

复合开闭原则，即通过扩展实现新功能

描述：定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序(稳定)而变化（扩展，子类化）。

总结：

• Strategy及其子类为组件提供了一系列可重用的算法，从而可以使 得类型在运行时方便地根据需要在各个算法之间进行切换。
• Strategy模式提供了用条件判断语句以外的另一种选择，消除条件 判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需 要Strategy模式。往往在出现if-else/switch-case语句的地方且其有拓展需求的情况下，我们可以用Strategy替换
• 如果Strategy对象没有实例变量，那么各个上下文可以共享同一个 Strategy对象，从而节省对象开销。(即可以减少if-else语句中一些非必要分支造成的臃肿)

观察者模式/Observer Event

描述：

• 定义对象间的一种一对多（变化）的依赖关系，以便当一个对象(Subject)的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。

总结：

• 对象维护一个Observer的List，当对象状态更改时发送信号，后由List内的Observers自行处理
• 使用面向对象的抽象， Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合。
• 目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播，观察者自己决定是否需要订阅通知，目标对象对此一无所知。
• Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式一个重要组成部分。

单一职责

在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。

装饰器模式/Decorator

描述：

• 符合设计原则中”优先使用对象组合，而不是类继承”的原则，防止因为过度使用继承所造成的代码臃肿

• 一般来说既继承父类又维护一个父类的指针的类一般就采用了Decorator模式

• 动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码&减少子类个数）。

总结：

• 通过采用组合而非继承的手法，Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的“灵活性差”和“多子类衍生问题”。
• Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。
• Decorator模式的目的并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

桥模式/Bridge

理解：

• 类似于是对Decorator模式的扩展，即不同变化方向的类拥有不同的基类，以免混淆（把Decorator中的Component拆开了）
• 是替代多进程的更好解决方案

描述：

• 将抽象部分(业务功能)与实现部分(平台实现)分离，使它们都可以独立地变化。

总结：

• Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自纬度的变化，即“子类化”它们。
• Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
• Bridge模式的应用一般在“两个非常强的变化维度”，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式。

对象创建

通过 “对象创建”模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。

工厂模式/Factory Method

类图中的虚线代表产生/生成

描述：

• 定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的：解耦，手段：虚函数）到子类。

总结：

• Factory Method模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系(new)会导致软件的脆弱。
• Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。
• Factory Method模式解决“单个对象”的需求变化。缺点在于要求创建方法/参数相同

抽象工厂/Abstract Factory

理解：

• 相当于是工厂模式的扩展，这里的工厂不只需要产生孤立的对象，而是需要产生一组相互有联系的对象

描述：

• 提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。

总结：

• 如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的工厂完全可以。
• “系列对象”指的是在某一特定系列下的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖。
• Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。

原型模式/Prototype

理解：

• 通过克隆构造新对象,相当于拷贝构造函数的思想
• 可以比较方便地创建结构较复杂的对象（复制状态，只需创建一次，之后通过复制自身产生更多对象），使用场景较少

描述：

• 使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。

总结：

• Prototype模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些“易变类”拥有“稳定的接口”。
• Prototype模式对于“如何创建易变类的实体对象”采用”原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象一一所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方Clone。
• Prototype模式中的Clone方法可以利用某些框架中的序列化来实现深拷贝。

构建器模式/Builder

理解：

• 个人理解：相当于在工厂模式前加一个Director，用其来控制工厂的对象产生

描述：

• 将一个复杂对象的构建与其表示相分离，使得同样的构建过程(稳定)可以创建不同的表示(变化)。

总结：

• Builder 模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
• 变化点在哪里，封装哪里—— Builder模式主要在于应对“复杂对 象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。
• 在Builder模式中，要注意不同语言中构造器内调用虚函数的差别（C++ vs. C#）

对象性能

面向对象很好地解决了“抽象”的问题，但是必不可免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理。

单件模式/Singleton

理解:

• 将构造函数private/protected隐藏，使用的实例化方法只返回一个实例

定义：

• 保证一个类仅有一个实例，并提供一个该实例的全局访问点。

总结： -Singleton模式中的实例构造器可以设置为protected以允许子类 派生。

• Singleton模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致多个对象实例，与Singleton模式的初衷违背。
• 如何实现多线程环境下安全的Singleton？注意对双检查锁的正确实现。（注意避免reorder，使用volitale）

享元模式/FlyWeight

理解：

• 当有很多琐碎的小对象时，我们可以通过存贮flyweight(Key)的形式将其存储在一个类中

定义：

• 运用共享技术有效地支持大量细粒度的对象。

总结：

• 面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。
• Flyweight采用对象共享（用一个类表示多个同类对象，常常该对象时只读的）的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。
• 对象的数量太大从而导致对象内存开销加大一一什么样的数量才算大？这需要我们仔细的根据具体应用情况进行评估，而不能凭空臆断。

接口隔离

注意，该模式具体实现可能会复杂，这里只设计概念(overview)理解

在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题、甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。

门面模式/Facade

理解：

• 增加一层封装，以简化使用，隔离变化

定义：

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

总结：

• 从客户程序的角度来看，Facade模式简化了整个组件系统的接口对于组件内部与外部客户程序来说，达到了一种“解耦”的效果内部子系统的任何变化不会影响到Facade接口的变化。
• Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
• Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。

代理模式/Proxy

注意，该模式具体实现可能会复杂，这里只设计概念(overview)理解

理解：

• 在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。
• 如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。
• 实现对对象的间接访问即代理

定义：

• 对这个为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。

总结：

• “增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的proxy对象便是解决这一问题的常用手段。
• 具体proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块提供抽象代理层,在架构层次对对象做proxy。
• Proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。

适配器模式/Adapter

理解：

• 实现不同版本/接口的兼容与转化
• 转接头

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

总结：

• Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。
• 书中定义了两种Adapter模式的实现结构：对象适配器和类适配器。但类适配器采用“多继承”的实现方式，一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神。
• Adapter模式可以实现的非常灵活，不必拘泥于书中定义的两种结构。例如，完全可以将Adapter模式中的“现存对象”作为新的接口方法参数，来达到适配的目的。

中介者模式/Mediator

理解：

• 在两个类交互时充当中间层，实现松耦合
• 直接依赖->间接依赖

定义：

• 用一个中介对象来封装（封装变化）一系列的对象交互。中介者使各对象不需要显式的相互引用（编译时依赖→运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互。

总结：

• 将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。
• 随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。
• Facade模式是解耦系统间（单向）的对象关联关系；Mediator模式是解耦系统内各个对象之间（双向）的关联关系。

状态变化

在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。

状态模式/State

理解：

• 即对一个对象的不同状态分别使用不同的类，用以支持在不同状态下的不同行为
• 可以类比Strategy模式

定义：

• 允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为

总结：

• State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。
• 为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的一即要么彻底转换过来，要么不转换。
• 如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。

备忘录模式/Memento

理解：

• 对当前状态进行快照并存储，以后可以恢复
• 状态的备份

定义：

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

总结：

• 备忘录（Memento）存储原发器（Originator）对象的内部状态，在需要时恢复原发器状态。
• Memento模式的核心是信息隐藏，即Originator需要向外接隐藏信息，保持其封装性。但同时又需要将状态保持到外界（Memento）。
• 由于现代语言运行时（如C#、Java等）都具有相当的对象序列化支持，因此往往采用效率较高、又较容易正确实现的序列化方案来实现Memento模式。

数据结构

常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件的复用。这时候，将这些特定数据结构封装在内部，在外部提供统一的接口，来实现与特定数据结构无关的访问，是一种行之有效的解决方案。

组合模式/Composite

理解：

• 是树状结构的一种更好实现，将叶节点(leaf)和主节点(Composite)都继承于同一父类(Component)，降低了对于不同节点需要不同处理的复杂度(具有一致性)
• 有多态递归的思想（体现在Operation方法中）

定义：

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

总结：

• Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地（复用）处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器。
• 将“客户代码与复杂的对象容器结构”解耦是Composite的核心思想，解耦之后，客户代码将与纯粹的抽象接口一一而非对象容器的内部实现结构————发生依赖，从而更能“应对变化”。
• Composite模式在具体实现中，可以让父对象中的子对象反向追溯;如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。

迭代器模式/Iterator

定义：

• 提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露（稳定）该对象的内部表示。

总结：

• 迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示。
• 迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作。
• 迭代器的健壮性考虑：遍历的同时更改迭代器所在的集合结构，会导致问题。
• 在Cpp中一般采用STL提供的模版迭代器（编译时迭代效率高于运行时迭代）

职责链模式/Chain of Resposibility

理解：

• 一个指向自身的基类，表示多态递归，产生了一个链表，请求随链表向下游传递，直到出现一个负责处理请求的位置为止。

定义：

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

总结：

• Chain of Responsibility模式的应用场合在于”一个请求可能有多个接受者，但是最后真正的接受煮只有一个“这时候请求发送就者与接受者的耦合有可能出现”变化脆弱”的症状，职责链的目的就是将两者解耦，从而好地应对变化。
• 应用了Chain of Responsibility模式后，对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。
• 如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每个接受对象的责任，而不是发出请求的对象的责任。

行为变化

在组件的构建过程中，组件行为的变化经常导致组件本身剧烈的变化。“行为变化”模式将组件的行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦合。

命令模式/Command

定义：

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

总结：

• Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。
• 实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式，可以将多个“命令”封装为一个“复合命令”MacroCommand。
• Command模式与C++中的函数对象有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，但有性能损失；C++函数对象以函数签名来定义行为接口规范，更灵活，性能更高。

访问器模式/Visitor

理解：

• 进行了两次的多态辨析以用于支持添加类新功能
• 过程：Vistor -> ElementBase.accept(Vistor) -> ElementA.accept(Vistor) -> Vistor.visitA

定义：

• 表示一个作用于某对象结构中的各元素的操作。使得可以在不改变（稳定）各元素的类的前提下定义（扩展）作用于这些元素的新操作（变化）。

总结：

• Visitor模式通过所谓双重分发（doubledispatch）来实现在不更改（不添加新的操作-编译时）Element类层次结构的前提下，在运行时透明地为类层次结构上的各个类动态添加新的操作（支持变化）
• 所谓双重分发即Visitor模式中间包括了两个多态分发（注意其中的多态机制）：第一个为accept方法的多态辨析；第二个为visitElementx方法的多态辨析。
• Visitor模式的最大缺点在于扩展类层次结构（增添新的Element子类），会导致Visitor类的改变（即我们在增减Element子类个数时需要一并修改Vistor的相关操作）。因此Vistor模式适用于：“Element类层次结构稳定，而其中的操作却经常面临频繁改动”。

领域规则

在特定领域中，某些变化虽然频繁，但可以抽象为某种规则。这时候，结合特定领域，将问题抽象为语法规则，从而给出在该领域下的一般性解决方案。

解析器模式/Interpreter

理解：

• 将抽象出来的规则定义为一个对象，用于解析具体的内容Context

定义：

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

总结：

• Interpreter模式的应用场合是Interpreter模式应用中的难点，只有满足“业务规则频繁变化，且类似的结构不断重复出现，并且容 抽象为语法规则的问题”才适合使用lnterpreter模式。
• 使用Interpreter模式来表示文法规则，从而可以使用面向对象技巧来方便地“扩展”文法。
• Interpreter模式比较适合简单的文法表示，对于复杂的文法表示，Interperter模式会产生比较大的类层次结构，需要求助于语法分析生成器这样的标准工具。