23种设计模式--行为型模式

模板模式

基本介绍：

• 模板方法模式，又叫做模板模式，在一个抽象类中公开定义它的方法模板。它的子类可以按需重写方法实现。但调用将以抽象类中的定义的方式进行
• 简单来说，模板方法模式定义了一个操作中的算法的骨架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构，就可以定义该算法的某些特定步骤
• 属于行为模式
• 

钩子方法：

• 在模板方法模式的父类中，可以定义一个方法，默认不做任何事情，子类可以视情况要不要覆盖它，该方法称为“钩子”

命令模式

基本介绍：

• 命令模式，在软件设计中，我们经常需要像某些对象发送请求，但是并不知道请求的接收者是谁，也不知道被请求的操作是哪个，我们只需要在程序运行时指定具体的请求接受者即可，此时可以使用命名模式来进行设计
• 命令模式使得请求发送者与请求接受者消除彼此的耦合，让对象之间的调用关系更加灵活，实现解耦
• 在命令模式中将一个请求封装成一个对象，以便使用不同的参数表示不同的请求（即命令）,同时命令模式也支持可撤销的操作
• 通俗的来说，将军发布命令，士兵去执行。其中的角色：将军（命令的发布者），士兵（命令的具体执行者），命令（连接将军和士兵）
• 

注意事项和细节：

• 将发起请求的对象与执行请求的对象解耦。发起请求的对象时调用者，调用者只要调用命令对象的execute方法就可可以让接受者工作，而不必知道具体的接受对象是谁，是 如何实现的，命令对象会负责让接收者执行请求的动作。也就是说：请求发起者和请求接受者之间的解耦是通过命令对象实现的，命令对象起到了纽带的作用
• 容易设计一个命令队列。只要将命令对象放入到一个队列中，就可以多线程的执行命令
• 容易实现对请求的撤销和重做
• 命令模式的不足：可能导致某些系统有过多的具体命令类，增加系统的复杂度
• 空命令也是一种设计模式，他为我们省去判空的操作

访问者模式

基本介绍：

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

• 主要将数据结构和数据操作分离，解决数据结构和操作耦合的问题

• 访问者模式的基本原理：在被访问的类中添加一个对外提供接待访问者的接口

• 应用场景：需要对一个对象结构中的对象进行很多不同操作（操作之间没有关联），同时需要避免让这些操作“污染”这些对象。

• 

  • Visitor：抽象访问者，为该数据结构中的每一个ConcreteElement声明一个visitor操作
  • ConcreteVisitor：具体的访问值，实现每个有visitor操作
  • 枚举它的元素，可以提供一个高层接口，用来允许访问者访问它的元素
  • element定义了一个accept方法，接受一个访问者

  双分派：

  所谓双分派是指不管类怎么变化，我们都能找到期望的方法运行。双分派意味着执行的操作却决于请求的种类和两个接受者的类型

注意事项和细节：

• 优点
  • 访问者模式符合单一职责原则，让程序具有优秀的扩展性，灵活性非常高
  • 访问者可以对功能进行统一，可以做报表，UI，拦截器与过滤器，适用于数据结构相对稳定的系统
• 缺点：
  • 具体元素对访问者公布细节，也就是说访问者关注了其他类的内部细节，这是迪米特法则所不建议的，这样会造成具体元素变更比较困难
  • 违背了依赖倒置原则。访问者依赖的是具体元素，而不是抽象元素
  • 因此，如果一个系统有比较稳定的数据结构，又经常变化的功能需求，那么访问者模式是非常适合的

迭代器模式

基本介绍：

• 迭代器模式是常用的的设计模式，属性行为型模式

• 如果我们的集合元素是用不同的方式实现的，当客户端要遍历这样元素时就要使用多种遍历方式，而且还会暴露元素的内部结构，可以考虑使用迭代器模式

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

• 

• Iterator：迭代器接口，由系统提供

• ConcreteIterator：具体的迭代器类，管理迭代

• Aggregate：统一的聚合接口，将客户端和具体的集合解耦

• ConcreteAggregate：具体的聚合，持有对象集合，并提供一个方法返回迭代器，该迭代器可以正确遍历集合

注意事项和细节

• 优点：
  • 提供一个统一的方法遍历对象，客户不用考虑聚合的类型，使用一种方法就可以遍历对象
  • 隐藏了聚合的内部结构，客户端要遍历聚合的时候只能取到迭代器，而不会知道聚合的具体组成
  • 提供一种设计思想，就是一个类应该只有一个引起变化的原因（单一职责原则）。在这种聚合类中，我们把迭代器分开，就是要把管理对象集合和遍历对象集合的责任分开，这样一来集合改变的话，只会影响到聚合对象。而遍历方式改变的话，只会影响到迭代器
• 缺点
  • 每个聚合对象都要一个迭代器，会生成多个迭代器，不好管理

观察者模式

中介者模式

基本介绍：

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

• 中介者模式属于行为型，使代码易于维护

• 比如MVC模式中，C（controller）是M（model）和V（view）的中介者，在前后端交互时起到了中间人的作用

• 

• Mediator：抽象中介者，定义了同事对象到中介者对象的从接口

• Colleague：抽象同事类

• ConcreteMediator：具体的中介者对象，实现抽象方法，需要所有的具体同事类，即使用一个集合来管理，并接受对象消息，完成下相应的任务

• ConcreteCollague：具体的同事类，但是它们都依赖中介者对象

注意事项和细节

• 多个类相互耦合，会形成网状结构，使用中介者模式将网状结构分离为星型结构，进行解耦
• 减少类间依赖，降低了耦合，符合迪米特法则
• 中介者承担了较多责任，一旦中介者出现问题，整个系统就会收到影响
• 如果设计不当，中介者对象本身会变得过于复杂

备忘录模式

基本介绍：

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

• origin：需要保存状态的对象
• memento：备忘录对象，负责保存好记录，即origin的内部状态
• careTaker：守护者对象，负责保存多个备忘录对象，使用集合管理，提高效率

注意事项和细节

• 给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史状态
• 实现了信息地封装，使得用户不需要关心状态的保存细节
• 如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存
• 为了节约内存，备忘录模式可以和原型模式配合使用

解释器模式

基本介绍：

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

• 

• context：环境角色，包含解释器之外的全局信息

• AbsExpression：抽象表达式，声明一个抽象的解释操作，这个方法为抽象语法树中所有的节点所共享

• TerminalExpression：为终结符表达式，实现和文法中的终结符相关的解释操作

• NonTerminalExpression：为非终结符表达式，为文法中的非终结符实现解释操作

状态模式

基本介绍：

• 它主要用来解决对象在多种状态转换时，需要对外输出不同的行为问题，状态和行为是一一对应的，状态之间可以相互转化

• 当一个对象的内在状态发生改变时，允许改变其行为，这个对象看起来像是改变了其类

• 

• context：环境角色，用于维护ConcreteState实例

• state：抽象状态角色，定义一个接口，封装一个与context的一个特点接口相关行为

• ConcreteState：具体的状态角色，每个子类实现一个与context的一个状态相关行为

注意事项和细节

• 代码具有很强的可读性，状态模式将每个状态封装到一个对应的类中
• 方便维护。将容易产生问题的if-else语句删除，如果把每个状态的行为都放到一个类中，每次调用都需要判断当前是什么状态，不但会产出很多if-else语句，而且容易出错
• 符合开闭原则，容易增删状态
• 会产生很多类。每个状态都要一个对应的类，当状态过多时会产生很多类，加大维护难度
• 当一个事件或者对象有很多状态时，状态之间会相互转换，对不同的状态要求有不同的行为的时候，可以考虑使用状态模式

策略模式

基本介绍

• 策略模式：定义算法族，分别封装起来，让他们之间可以互相替代，此模式让算法的变化独立于使用算法的客户
• 

注意事项和细节

• 策略模式的关键是：分析项目中变化部分与不变部分
• 核心思想是：多用聚合和组合，少用继承；用行为类组合，而不是行为的继承。更有弹性
• 提供了可以替换继承关系的办法：策略模式将算法封装到独立的strategy类中使得可以独立于其他context改变它，使它易于切换，易于理解，易于拓展
• 需要注意的是，每添加一个策略就要添加一个类，当策略过多时，是会导致类数据庞大。

职责链模式

基本介绍

• 职责链模式：又名责任链模式，为请求者创建了一个接收者对象的链。这种模式对请求的发送者和接收者进行解耦

• 职责链模式通常每一个接收者都包含一对另一个接收者的引用。如果一个对象不能处理该请求，那么他会把相同的请求传给下一个接收者，以此类推。

• 

• Handler：抽象的处理者，定义了一个处理请求的接口，同时含义另外的handler

• ConcreteHandler：具体的处理者，处理它自己负责的请求，可以访问它的后继者（即下一个处理者），如果可以处理当前请求，则处理，否则就将该请求交给后继者处理，从而形成一个职责链

• request：含义多个属性，表示一个请求

注意事项和细节

• 将请求和处理分开，实现解耦，提高系统的灵活性
• 简化了对象，使对象不需要知道链的结构
• 性能会受到影响，特别使在链比较长的时候，因此需控制链中最大节点数量，一般通过在handler中设置一个最大节点数，在setNext（）方法中判断是否超过阙值，超过则不允许该链建立，避免出现超长链无意识破坏系统性能
• 调试不方便。采用了类似递归的方式，调试时逻辑可能比较复杂