李建忠讲23种设计模式笔记-下

前两天在B站看了李建忠老师讲23种设计模式的系列视频，收获颇丰。设计模式是前人的智慧和经验的总结，需要我们反复地学习、在实践中体会其蕴含的设计原则和设计思想。李老师按照封装变化将23种设计模式分成组件协作、单一职责、对象创建、对象性能、接口隔离、状态变化、数据结构、行为变化和领域问题九类，为我们理解设计模式提供了新角度。现将李老师的讲课内容整理出来，与大家分享～内容较长，分为上下两篇，本文是第二篇
上篇👉：https://blog.csdn.net/mg2flyingff/article/details/105310045

接口隔离

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

典型模式

• Façade(门面模式)
• Proxy
• Adapter
• Mediator(中介者)

第十四讲：设计模式之 Façade 门面模式

动机

• 上述A方案的问题在于组件的客户和组件中各种复杂的子系统有过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合会面临很多变化的挑战
• 如何简化外部客户程序和系统间的交互接口，如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？

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

结构

要点总结

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

第十五讲：设计模式之 Proxy 代理模式

动机

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

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

结构

要点总结

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

第十六讲：设计模式之 Adapter 适配器模式

动机

• 在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中使用，但是新环境要求的接口是这些现存对象所不满足的
• 如何应对这种“迁移的变化”，如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？

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

结构

继承新接口，组合旧接口

要点总结

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

第十七讲：设计模式之 Mediator 中介者模式

动机

• 在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将会面临不断的变化
• 在这种情况下，我们可以使用一个“中介对象”来关系对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化

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

结构

要点总结

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

“状态变化” 模式

在组件构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效地管理，同时又维持高层模块的稳定？“状态变化”模式为这一问题提供了一种解决方案

典型模式

• Memento(备忘录)
• State

第十八讲：设计模式之 State 状态模式

动机

• 在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为可能完全不同
• 如何在运行时根据对象的状态来透明地更改对象的行为，而不会为对象操作和状态转换之间引入紧耦合？

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

结构

要点总结

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

第十九讲：设计模式之 Memento 备忘录模式

动机

• 在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现
• 如何实现对象状态的良好保存与恢复，但同时又不会因此而破坏对象本身的封装性？

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

结构

要点总结

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

“数据结构”模式

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

典型模式

• Composite(组合模式)
• Iterator
• Chain of Resposibility(职责链)

第二十讲：设计模式之 Composite 组合模式

动机

• 软件在某些情况下，客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部实现结构（而非抽象接口）的变化将引起客户代码的频繁变化，为代码的维护性、扩展性等带来了弊端
• 如何将“客户代码与复杂的对象容器结构”解耦，让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器？

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

结构

要点总结

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

第二十一讲：设计模式之 Iterator 迭代器模式

动机

• 在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其包含的元素；同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能
• 使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方式

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

结构

要点总结

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

第二十二讲：设计模式之 Chain of Resposibility 责任链模式

动机

• 在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者；如果显示指定，将不可避免地带来发送者和接受者的紧耦合
• 如何使请求的发送者不需要指定具体的接受者，让请求的接受者自己在运行时决定来处理请求，从而使两者解耦？

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

结构

要点总结

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

“行为变化”模式

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

典型模式

• Command
• Visitor

第二十三讲：设计模式之 Command 命令模式

动机

• 在软件构建过中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合 — 比如需要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的
• 在这种情况下，如何将“行为请求者”与“行为实现者”解耦，将一组行为抽象为对象，可以实现二者之间的松耦合

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

结构

要点总结

• Command 模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“ 将行为抽象为对象 ”
• 实现Command 接口的具体命令对象 ConcreteCommand 有时候根据需要可能会保存一些额外的状态信息。通过使用 Composite 模式，可以将多个“命令”封装为一个“ 复合命令 ” MacroCommand

第二十四讲：设计模式之 Visitor 访问者模式

动机

• 在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计
• 如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？

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

结构
要点总结

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

领域问题

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

典型模式

• Interpreter

第二十五讲：设计模式之 Interpreter 解释器模式

动机

• 在软件构建过程中，如果某一特定领域的问题比较复杂，类似的结构不断重复出现，如果使用普通的变成方式来实现将面临非常频繁的变化
• 在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的

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

结构

要点总结

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

第二十六讲：设计模式总结

设计模式的目标：管理变化，提高复用！

• 八大原则、重构技法、模式分类
• 现代较少用的模式： Builder、Mediator、Memento、Iterator、Chain of Resposibility、Command、Visitor、 Interpreter
• 关注变化点和稳定点：设计模式-隔离变化点和稳定点
• 什么时候不用模式
  – 代码可读性差时
  – 需求理解还很浅时
  – 变化还没有显现时
  – 不是系统的关键点时
  – 项目没有复用价值时
  – 项目将要发布时
• 经验之谈
  – 不要为模式而模式
  – 关注抽象类 & 接口
  – 理清变化点和稳定点
  – 审视依赖关系
  – 要有 Framework 和 Application 的区隔思维
  – 良好的设计是演化的结果（不是一步到位的）
• 设计模式成长之路
  – “手中无剑，心中无剑”：见模式而不知
  – “手中有剑，心中无剑”：可以识别模式，作为应用开发人员使用模式
  – “手中有剑，心中有剑”：作为框架开发人员为应用设计某些模式
  – “手中无剑，心中有剑”：忘掉模式，只有原则
• 设计模式总览

设计模式	定义
Template Method	定义一个操作中的算法的骨架（稳定），而将一些步骤延迟（变化）到子类中。Template Method 使得子类可以不改变（复用）一个算法的结构即可重定义（override 重写）该算法的某些特定步骤
Strategy	定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序（稳定）而变化（扩展、子类化）
Observer/Event	定义对象间的一种一对多（变化）的依赖关系，以便当一个对象（Subject）的状态发生改变时，所有依赖于它的对象都能得到通知并自动更新
Decorator	动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator 模式比生成子类（继承）更为灵活（消除重复代码 & 减少子类个数）
Bridge	将抽象部分（业务功能）与实现部分（平台实现）分离，使它们都可以独立地变化
Factory Method	定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使得一个类的实例化延迟（目的：解耦；手段：抽象方法）到子类
Abstract Factory	提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类
Prototype	使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象
Builder	将一个复杂对象的构建与其表示相分离，使得同样的构建过程（稳定）可以创建不同的表示（变化）
Singleton	保证一个类仅有一个实例，并提供一个该实例的全局访问点
Flyweight	运用共享技术有效地支持大量细粒度的对象
Facade	为子系统中的一组接口提供一个一致（稳定）的界面，Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）（隔离变化和稳定）
Proxy	为其他对象提供一种代理以控制（隔离 ，即使用接口）对这个对象的访问
Mediator	用一个中介对象来封装（封装变化）一系列的对象交互。中介者使各对象不需要显式的相互引用（编译时依赖 -> 运行时依赖 ），从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互
Adapter	将一个类的接口转成客户希望的另一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
Memento	在不破环封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态
State	允许一个对象在其内部状态改变时改变它的行为，从而使对象看起来似乎修改了其行为
Composite	将对象组合成树形结构以表示“部分-整体”的层次结构。Composite 使得用户对单个对象和组合对象的使用具有一致性（稳定）
Iterator	提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露（稳定）该对象的内部表示
Chain of Responsibility	使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，知道有一个对象处理它为止
Command	将一个请求（行为）封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作
Visitor	表示一个作用于某对象结构中的各元素的操作。使得可以在不改变（稳定）各元素的类的前提下定义（扩展）作用于这些元素的新操作（变化）
Interpreter	给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子