行为型设计模式

一、概述

这些设计模式特别关注对象之间的通信

• 责任链模式（Chain of Responsibility Pattern）
• 命令模式（Command Pattern）
• 解释器模式（Interpreter Pattern）
• 迭代器模式（Iterator Pattern）
• 中介者模式（Mediator Pattern）
• 备忘录模式（Memento Pattern）
• 观察者模式（Observer Pattern）
• 状态模式（State Pattern）
• 策略模式（Strategy Pattern）
• 模板模式（Template Pattern）
• 访问者模式（Visitor Pattern）

二、责任链模式（Chain of Responsibility Pattern）

1. 职责链模式（Chain of Responsibility Pattern）, 又叫 责任链模式，为请求创建了一个接收者对象的链。这种模式对请求的发送者和接收者进行解耦。
2. 职责链模式通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。

1. Handler : 抽象的处理者, 定义了一个处理请求的接口, 同时含义另外 Handler
2. ConcreteHandlerA , B 是具体的处理者, 处理它自己负责的请求， 可以访问它的后继者(即下一个处理者), 如果可以处理当前请求，则处理，否则就将该请求交个 后继者去处理，从而形成一个职责链
3. Request ， 含义很多属性，表示一个请求

缺点：

1. 性能会受到影响，特别是在链比较长的时候，因此需控制链中最大节点数量，一般通过在 Handler 中设置一个最大节点数量，在 setNext()方法中判断是否已经超过阀值，超过则不允许该链建立，避免出现超长链无意识地破坏系统性能
2. 调试不方便。采用了类似递归的方式，调试时逻辑可能比较复杂

最佳应用场景：有多个对象可以处理同一个请求时，比如：多级请求、请假/加薪等审批流程、Java Web 中 Tomcat对 Encoding 的处理、拦截器

三、命令模式（Command Pattern）

命令模式：请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。

命名模式使得请求发送者与请求接收者消除彼此之间的耦合，让对象之间的调用关系更加灵活，实现解耦。

1. Invoker 是调用者角色
2. Command: 是命令角色，需要执行的所有命令都在这里，可以是接口或抽象类
3. Receiver: 接受者角色，知道如何实施和执行一个请求相关的操作
4. ConcreteCommand: 将一个接受者对象与一个动作绑定，调用接受者相应的操作，实现 execute

命令模式的注意事项和细节

1. 将发起请求的对象与执行请求的对象解耦。发起请求的对象是调用者，调用者只要调用命令对象的 execute()方法就可以让接收者工作，而不必知道具体的接收者对象是谁、是如何实现的，命令对象会负责让接收者执行请求的动作，也就是说：”请求发起者”和“请求执行者”之间的解耦是通过命令对象实现的，命令对象起到了纽带桥梁的作用
2. 容易设计一个命令队列。只要把命令对象放到列队，就可以多线程的执行命令
3. 容易实现对请求的撤销和重做
4. 命令模式不足：可能导致某些系统有过多的具体命令类，增加了系统的复杂度，这点在在使用的时候要注意
5. 空命令也是一种设计模式，它为我们省去了判空的操作。在上面的实例中，如果没有用空命令，我们每按下一个按键都要判空，这给我们编码带来一定的麻烦
6. 命令模式经典的应用场景：界面的一个按钮都是一条命令、模拟 CMD（DOS 命令）订单的撤销/恢复、触发- 反馈机制

四、解释器模式（Interpreter Pattern）

解释器模式（Interpreter Pattern）：是指给定一个语言(表达式)，定义它的文法的一种表示，并定义一个解释器，使用该解释器来解释语言中的句子(表达式)

1. Context: 是环境角色,含有解释器之外的全局信息
2. AbstractExpression: 抽象表达式， 声明一个抽象的解释操作,这个方法为抽象语法树中所有的节点所共享
3. TerminalExpression: 为终结符表达式, 实现与文法中的终结符相关的解释操作
4. NonTermialExpression: 为非终结符表达式，为文法中的非终结符实现解释操作

注意事项和细节

1. 当有一个语言需要解释执行，可将该语言中的句子表示为一个抽象语法树，就可以考虑使用解释器模式，让程序具有良好的扩展性
2. 应用场景：编译器、运算表达式计算、正则表达式、机器人等
3. 使用解释器可能带来的问题：解释器模式会引起类膨胀、解释器模式采用递归调用方法，将会导致调试非常复杂、效率可能降低

五、迭代器模式（Iterator Pattern）

迭代器模式，提供一种遍历集合元素的统一接口，用一致的方法遍历集合元素，不需要知道集合对象的底层表示，即：不暴露其内部的结构

1. Iterator ： 迭代器接口，是系统提供，含义 hasNext, next, remove
2. ConcreteIterator : 具体的迭代器类，管理迭代
3. Aggregate :一个统一的聚合接口， 将客户端和具体聚合解耦
4. ConcreteAggreage : 具体的聚合持有对象集合， 并提供一个方法，返回一个迭代器， 该迭代器可以正确遍历集合
5. Client :客户端， 通过 Iterator 和 Aggregate 依赖子类

最典型的应用就是集合的遍历。注意事项和细节：

1. 提供一个统一的方法遍历对象，调用方不用再考虑聚合的类型，使用一种方法就可以遍历对象了
2. 隐藏了聚合的内部结构，客户端要遍历聚合的时候只能取到迭代器，而不会知道聚合的具体组成
3. 提供了一种设计思想，就是一个类应该只有一个引起变化的原因（叫做单一责任原则）。在聚合类中，我们把迭代器分开，就是要把管理对象集合和遍历对象集合的责任分开，这样一来集合改变的话，只影响到聚合对象。而如果遍历方式改变的话，只影响到了迭代器
4. 当要展示一组相似对象，或者遍历一组相同对象时使用, 适合使用迭代器模式
5. 缺点：每个聚合对象都要一个迭代器，会生成多个迭代器不好管理类

六、中介者模式（Mediator Pattern）

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

比如 MVC 模式，C（Controller 控制器）是 M（Model 模型）和 V（View 视图）的中介者，在前后端交互时起到了中间人的作用

1. Mediator 就是抽象中介者,定义了同事对象到中介者对象的接口
2. Colleague 是抽象同事类
3. ConcreteMediator 具体的中介者对象, 实现抽象方法, 他需要知道所有的具体的同事类,即以一个集合来管理HashMap,并接受某个同事对象消息，完成相应的任务
4. ConcreteColleague 具体的同事类，会有很多, 每个同事只知道自己的行为，而不了解其他同事类的行为(方法)，但是他们都依赖中介者对象

注意事项和细节

1. 多个类相互耦合，会形成网状结构, 使用中介者模式将网状结构分离为星型结构，进行解耦
2. 中介者承担了较多的责任，一旦中介者出现了问题，整个系统就会受到影响
3. 如果设计不当，中介者对象本身变得过于复杂，这点在实际使用时，要特别注意

七、备忘录模式（Memento Pattern）

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

1. originator : 对象(需要保存状态的对象)
2. Memento ： 备忘录对象,负责保存好记录，即 Originator 内部状态
3. Caretaker：守护者对象,负责保存多个备忘录对象， 使用集合管理，提高效率
4. 说明：如果希望保存多个 originator 对象的不同时间的状态，也可以，只需要要 HashMap <String, 集合>
5. 为了节约内存，备忘录模式可以和原型模式配合使用

八、观察者模式（Observer Pattern）

观察者模式又叫发布-订阅（Publish-Subscribe）模式，其中的订阅表示这些观察者对象需要向目标对象进行注册，这样目标对象才知道有哪些对象在观察它。发布指的是当目标对象的状态改变时，它就向它所有的观察者对象发布状态更改的消息，以让这些观察者对象知晓。

一个目标对象的观察者对象数量是不固定的，可以随时增加新的观察者对象或取消已有的观察者对象。观察者模式的主要优点就是极大地降低了目标对象和观察者对象间的耦合，二者可以独自地改变和复用，让对系统增加功能或删除功能都很方便。

1. Subject：目标类，它是一个抽象类，也是所有目标对象的父类。它用一个列表记录当前目标对象有哪些观察者对象，并提供增加、删除观察者对象和通知观察者对象的接口
2. Observer：观察者类，它也是一个抽象类，是所有观察者对象的父类；它为所有的观察者对象都定义了一个名为update的方法（也叫成员函数）。当目标对象的状态改变时，它就是通过调用它的所有观察者对象的update方法来通知它们的。
3. ConcreteSubject：具体目标类，可以有多个不同的具体目标类，它们同时继承Subject类。一个目标对象就是某个具体目标类的对象，一个具体目标类负责定义它自身的事务逻辑，并在状态改变时通知它的所有观察者对象。
4. ConcreteObserver：具体观察者类，可以有多个不同的具体观察者类，它们同时继承Observer类。一个观察者对象就是某个具体观察者类的对象。每个具体观察者类都要重定义Observer类中定义的update方法，在该方法中实现它自己的任务逻辑，当它被通知的时候（目标对象调用它的update方法）就执行自己特有的任务。

九、状态模式（State Pattern）

状态模式是一种通过将对象的状态转换逻辑分布到状态对象中来实现状态转换的设计模式。它将对象的行为与对应的状态分离，使得在修改对象状态时，不需要修改对象的行为方法。同时，状态模式可以通过将状态的转换逻辑包含在各个状态类中来简化代码，避免出现大量的条件判断语句，从而提高代码的可读性和可维护性。工作流中常用

1. Context 类为环境角色, 用于维护 State 实例,这个实例定义当前状态
2. State 是抽象状态角色,定义一个接口封装与 Context 的一个特点接口相关行为
3. ConcreteState 具体的状态角色，每个子类实现一个与 Context 的一个状态相关行为

十、策略模式（Strategy Pattern）

策略模式（Strategy Pattern）中，定义算法族（策略组），分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户

从上图可以看到，客户 context 有成员变量 strategy 或者其他的策略接口,至于需要使用到哪个策略，我们可以在构造器中指定

十一、模板模式（Template Pattern）

模板模式(Template Pattern)，指在一个抽象类公开定义了执行它的方法的模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。

简单说，模板方法模式 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构，就可以重定义该算法的某些特定步骤

十二、访问者模式（Visitor Pattern）

访问者模式（Visitor Pattern），封装一些作用于某种数据结构的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

主要将数据结构与数据操作分离，解决数据结构和操作耦合性问题。访问者模式的基本工作原理是：在被访问的类里面加一个对外提供接待访问者的接口

访问者模式主要应用场景是：需要对一个对象结构中的对象进行很多不同操作(这些操作彼此没有关联)，同时需要避免让这些操作"污染"这些对象的类，可以选用访问者模式解决

1. Visitor：是抽象访问者，为该对象结构中的 ConcreteElement 的每一个类声明一个 visit 操作
2. ConcreteVisitor ：是一个具体的访问值 实现每个有 Visitor 声明的操作，是每个操作实现的部分
3. ObjectStructure：能枚举它的元素， 可以提供一个高层的接口，用来允许访问者访问元素
4. Element：定义一个 accept 方法，接收一个访问者对象
5. ConcreteElement 为具体元素，实现了 accept 方法

访问者模式的注意事项和细节

1. 缺点：具体元素对访问者公布细节，也就是说访问者关注了其他类的内部细节，这是迪米特法则所不建议的, 这样造成了具体元素变更比较困难
2. 缺点：违背了依赖倒转原则。访问者依赖的是具体元素，而不是抽象元素

因此，如果一个系统有比较稳定的数据结构，又有经常变化的功能需求，那么访问者模式就是比较合适的

比如：去银行柜台办业务，一般情况下会开几个个人业务柜台的，你去其中任何一个柜台办理都是可以的。我们的访问者模式可以很好付诸在这个场景中：对于 银行柜台来说，他们是不用变化的，就是说今天和明天提供个人业务的柜台是不需要有变化的。而我们作为访问者，今天来银行可能是取消费流水，明天来银行可能 是去办理手机银行业务，这些是我们访问者的操作，一直是在变化的。

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