Typescript玩转设计模式之对象行为型模式（上）

时间 2019-11-29

标签 typescript 设计模式对象行为繁體版

原文原文链接

做者简介 joey 蚂蚁金服·数据体验技术团队html

继前面几篇设计模式文章以后，这篇介绍5个对象行为型设计模式。java

Chain of Responsibility（职责链）

意图

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

结构

职责链模式包含以下角色：github

Handler（抽象处理者）：它定义了一个处理请求的接口，通常设计为抽象类，因为不一样的具体处理者处理请求的方式不一样，所以在其中定义了抽象请求处理方法。由于每个处理者的下家仍是一个处理者，所以在抽象处理者中定义了一个抽象处理者类型的对象（如结构图中的successor），做为其对下家的引用。经过该引用，处理者能够连成一条链。
ConcreteHandler（具体处理者）：它是抽象处理者的子类，能够处理用户请求，在具体处理者类中实现了抽象处理者中定义的抽象请求处理方法，在处理请求以前须要进行判断，看是否有相应的处理权限，若是能够处理请求就处理它，不然将请求转发给后继者；在具体处理者中能够访问链中下一个对象，以便请求的转发。

示例

interface RequestData {
    name: string,
    increaseNum: number,
  }

  /**
   * 抽象处理者
   */
  abstract class Handler {
    protected next: Handler;
    setNext(next: Handler) {
      this.next = next;
    }
    abstract processRequest(request: RequestData): void;
  }

  class IdentityValidator extends Handler {
    processRequest(request: RequestData) {
      if (request.name === 'yuanfeng') {
        console.log(`${request.name} 是本公司的员工`);
        this.next.processRequest(request);
      } else {
        console.log('不是本公司员工');
      }
    }
  }

  class Manager extends Handler {
    processRequest(request: RequestData) {
      if (request.increaseNum < 300) {
        console.log('低于300的涨薪，经理直接批准了');
      } else {
        console.log(`${request.name}的涨薪要求超过了经理的权限，须要更高级别审批`);
        this.next.processRequest(request);
      }
    }
  }

  class Boss extends Handler {
    processRequest(request: RequestData) {
      console.log('hehe，想涨薪，你能够走了');
    }
  }

  function chainOfResponsibilityDemo() {
    const identityValidator = new IdentityValidator();
    const manager = new Manager();
    const boss = new Boss();
    // 构建职责链
    identityValidator.setNext(manager);
    manager.setNext(boss);

    const request: RequestData = {
      name: 'yuanfeng',
      increaseNum: 500,
    };
    identityValidator.processRequest(request);
  }

  chainOfResponsibilityDemo();
复制代码

适用场景

有多个对象能够处理一个请求，哪一个对象处理该请求运行时自动肯定，客户端只须要把请求提交到链上便可；
想在不明确指定接收者的状况下，向多个对象中的一个提交一个请求；
可处理一个请求的对象集合应被动态指定；

优势

下降耦合度。链中的对象不需知道链的结构；
加强了职责链组织的灵活性。能够在运行时动态改变职责链；

缺点

不保证被接受。一个请求可能得不处处理；
若是建链不当，可能会形成循环调用，将致使系统陷入死循环；

Command（命令）

意图

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

结构

命名模式包含如下角色：设计模式

Command（抽象命令类）：抽象命令类通常是一个抽象类或接口，在其中声明了用于执行请求的execute()等方法，经过这些方法能够调用请求接收者的相关操做。
ConcreteCommand（具体命令类）：具体命令类是抽象命令类的子类，实现了在抽象命令类中声明的方法，它对应具体的接收者对象，将接收者对象的动做绑定其中。在实现execute()方法时，将调用接收者对象的相关操做(Action)。
Invoker（调用者）：调用者即请求发送者，它经过命令对象来执行请求。一个调用者并不须要在设计时肯定其接收者，所以它只与抽象命令类之间存在关联关系。在程序运行时能够将一个具体命令对象注入其中，再调用具体命令对象的execute()方法，从而实现间接调用请求接收者的相关操做。
Receiver（接收者）：接收者执行与请求相关的操做，它具体实现对请求的业务处理。

示例

简单命令

// 点菜场景下，客户点餐后彻底不须要知道作菜的厨师是谁，记载着客户点菜信息的订单就是一个命令。

  // 命令的基类，只包含了一个执行方法
  class Command {
    execute(arg?): void {}
  }

  // 厨师类，每一个厨师都会作面包和肉
  class Cook {
    private name: string;
    constructor(name: string) {
      this.name = name;
    }
    makeBread() {
      console.log(`厨师 ${this.name} 在作面包`);
    }
    makeMeal() {
      console.log(`厨师 ${this.name} 在作肉`);
    }
  }

  // 简单命令只须要包含接收者和执行接口
  class SimpleCommand extends Command {
    // 接收者，在点菜系统里是厨师
    receiver: Cook;
  }

  // 作面包的命令类
  class BreadCommand extends SimpleCommand {
    constructor(cook: Cook) {
      super();
      this.receiver = cook;
    }
    execute() {
      this.receiver.makeBread();
    }
  }

  // 作肉的命令类
  class MealCommand extends SimpleCommand {
    constructor(cook: Cook) {
      super();
      this.receiver = cook;
    }
    execute() {
      this.receiver.makeMeal();
    }
  }

  // 系统启动时，将命令注册到菜单上，生成可被处处使用的命令对象
  function simpleCommandDemo(): void {
    const cook1 = new Cook('厨师1');
    const cook2 = new Cook('厨师2');

    // 生成菜单，上架销售，顾客能够选择点肉或点面包
    const breadCommand: Command = new BreadCommand(cook1);
    const mealCommand: Command = new MealCommand(cook2);

    // 客户点菜时，彻底不须要知道是哪一个厨师作的，只须要从菜单上点想要的菜，即下命令便可
    // 此时已经作到了命令的触发者与接收者的分离
    // 命令对象能够在整个系统中处处传递，如通过多个服务员，而不会丢失接受者的信息
    breadCommand.execute();
    mealCommand.execute();
  }
复制代码

可撤销命令

相比简单命令，除了在命令对象中保存了接收者，还须要存储额外的状态信息，如接收者上次执行操做的参数数组

class AdvancedCommand extends Command {
  // 接收者
  ball: Ball;
  // 额外状态信息，移动的距离
  pos: number;
  // 执行命令时候，向左移动，同时记录下移动的距离
  execute(pos: number) {
    this.pos = pos;
    this.ball.moveToLeft(pos);
  }
  // 撤销时执行反向操做
  unExecute() {
    this.ball.moveToRight(this.pos);
  }
}
复制代码

宏命令

同时容许多个命令，这里不须要显式的接收者，由于每一个命令都已经定义了各自的接收者bash

class MacroCommand extends Command {
  // 保存命令列表
  cmdSet: Set<Command> = [];
  add(cmd: Command): void {
    this.cmdSet.add(cmd);
  }
  remove(cmd: Command): void {
    this.cmdSet.delete(cmd);
  }
  execute(): void {
    this.cmdSet.forEach((cmd: Command) => {
      cmd.execute();
    });
  }
}
复制代码

适用场景

菜单场景。抽象出待执行的动做以参数化某对象。你可用过程语言中的“回调”函数表达这种参数化机制。所谓回调函数是指函数先在某处注册，而它将在稍后某个须要的时候被调用。Commond模式是回调机制的一个面向对象的替代品。
在不一样的时刻指定、排列和执行请求。一个Command对象能够有一个与初始请求无关的生存期。若是一个请求的接收者可用一种与地址空间无关的方式表达，那么就可将负责该请求的命令对象传送给另外一个不一样的进程并在那儿实现该请求。
支持取消操做。Command的Excute操做可在实施操做前将状态存储起来，在取消操做时这个状态用来消除该操做的影响。Command接口必须添加一个Unexecute操做，该操做取消上一次Execute调用的效果。执行的命令被存储在一个历史列表中。可经过向后和向前遍历这一列表并分别调用Unexecute和Execute来实现重数不限的“取消”和“重作“。

优势

将调用操做的对象与知道如何实现该操做的对象解耦；
能够将多个命令装配成一个宏命令；
增长新的命令很容易，由于无需改变已有的类；
为请求的撤销和恢复操做提供了一种设计和实现方案；

缺点

可能会致使系统里有过多的具体命令类。由于针对每个对请求接收者的调用操做都须要设计一个具体命令类，所以在系统中可能须要提供大量的具体命令类，这将影响命令模式的使用。

Iterator（迭代器）

意图

提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。编程语言

结构

迭代器模式包含如下角色：ide

Iterator（抽象迭代器）：它定义了访问和遍历元素的接口，声明了用于遍历数据元素的方法，例如：用于获取第一个元素的first()方法，用于访问下一个元素的next()方法，用于判断是否还有下一个元素的hasNext()方法，用于获取当前元素的currentItem()方法等，在具体迭代器中将实现这些方法。
ConcreteIterator（具体迭代器）：它实现了抽象迭代器接口，完成对聚合对象的遍历，同时在具体迭代器中经过游标来记录在聚合对象中所处的当前位置，在具体实现时，游标一般是一个表示位置的非负整数。
Aggregate（抽象聚合类）：它用于存储和管理元素对象，声明一个createIterator()方法用于建立一个迭代器对象，充当抽象迭代器工厂角色。
ConcreteAggregate（具体聚合类）：它实现了在抽象聚合类中声明的createIterator()方法，该方法返回一个与该具体聚合类对应的具体迭代器ConcreteIterator实例。

示例

相对于迭代器模式的经典结构，简化了实现，去除了抽象聚合类和具体聚合类的设计，同时简化了迭代器接口。

// 迭代器接口
interface Iterator {
  next(): any;
  first(): any;
  isDone(): boolean;
}

// 顺序挨个遍历数组的迭代器
class ListIterator implements Iterator {
  protected list: Array<any> = [];
  protected index: number = 0;
  constructor(list) {
    this.list = list;
  }
  first() {
    if (this.list.length) {
      return this.list[0];
    }
    return null;
  }
  next(): any {
    if (this.index < this.list.length) {
      this.index += 1;
      return this.list[this.index];
    }
    return null;
  }
  isDone(): boolean {
    return this.index >= this.list.length;
  }
}

// 跳着遍历数组的迭代器
// 因为跳着遍历和逐个遍历，区别只在于next方法，所以经过继承简单实现
class SkipIterator extends ListIterator {
  next(): any {
    if (this.index < this.list.length) {
      const nextIndex = this.index + 2;
      if (nextIndex < this.list.length) {
        this.index = nextIndex;
        return this.list[nextIndex];
      }
    }
    return null;
  }
}

// 对同一个序列，调用不一样的迭代器就能实现不一样的遍历方式，而不须要将迭代方法写死在序列中
// 经过迭代器的方式，将序列与遍历方法分离
function iteratorDemo(): void {
  const list = [1,2,3,4,5,6];

  // 挨个遍历
  const listIterator: Iterator = new ListIterator(list);
  while(!listIterator.isDone()) {
    const item: number = listIterator.next();
    console.log(item);
  }

  // 跳着遍历
  const skipIterator: Iterator = new SkipIterator(list);
  while(!listIterator.isDone()) {
    const item: number = skipIterator.next();
    console.log(item);
  }
}

// 内部迭代器，即在聚合内部定义的迭代器，外部调用不须要关心迭代器的具体实现，缺点是功能被固定，不易扩展
class SkipList {
  list = [];
  constructor(list: Array<any>) {
    this.list = list;
  }
  // 内部定义了遍历的规则
  // 这里实现为间隔遍历
  loop(callback) {
    if (this.list.length) {
      let index = 0;
      const nextIndex = index + 2;
      if (nextIndex < this.list.length) {
        callback(this.list[nextIndex]);
        index = nextIndex;
      }
    }
  }
}

function innerIteratorDemo(): void {
  const list = [1,2,3,4,5,6];
  const skipList = new SkipList(list);
  // 按照聚合的内部迭代器定义的规则迭代
  skipList.loop(item => {
    console.log(item);
  });
}
复制代码

适用场景

访问一个聚合对象的内容而无需暴露它的内部结构；
支持对聚合对象的多种遍历方式；
为遍历不一样的聚合结构提供一个统一的接口；

优势

它支持以不一样的方式遍历一个聚合对象，在同一个聚合对象上能够定义多种遍历方式；
迭代器简化了聚合类。因为引入了迭代器，在原有的聚合对象中不须要再自行提供数据遍历等方法，这样能够简化聚合类的设计；
在迭代器模式中，因为引入了抽象层，增长新的聚合类和迭代器类都很方便，无须修改原有代码，知足“开闭原则”的要求；

缺点

因为迭代器模式将存储数据和遍历数据的职责分离，增长新的聚合类须要对应增长新的迭代器类，类的个数成对增长，这在必定程度上增长了系统的复杂性；
抽象迭代器的设计难度较大，须要充分考虑到系统未来的扩展。在自定义迭代器时，建立一个考虑全面的抽象迭代器并非件很容易的事情。

Mediator（中介者）

意图

用一个中介对象来封装一系列的对象交互，中介者使各对象不须要显式地相互引用，从而使其耦合松散，并且能够独立地改变它们之间的交互。

结构

中介者模式包含如下角色：

Mediator（抽象中介者）：它定义一个接口，该接口用于与各同事对象之间进行通讯。
ConcreteMediator（具体中介者）：它是抽象中介者的子类，经过协调各个同事对象来实现协做行为，它维持了对各个同事对象的引用。
Colleague（抽象同事类）：它定义各个同事类公有的方法，并声明了一些抽象方法来供子类实现，同时它维持了一个对抽象中介者类的引用，其子类能够经过该引用来与中介者通讯。
ConcreteColleague（具体同事类）：它是抽象同事类的子类；每个同事对象在须要和其余同事对象通讯时，先与中介者通讯，经过中介者来间接完成与其余同事类的通讯；在具体同事类中实现了在抽象同事类中声明的抽象方法。

示例

租房的案例，租客和房主经过中介者联系，二者并不直接联系

// 抽象中介者
  abstract class Mediator {
    abstract contact(message: string, person: Human): void
  }

  // 抽象同事类
  abstract class Human {
    name: string
    mediator: Mediator
    constructor(name: string, mediator: Mediator) {
      this.name = name;
      this.mediator = mediator;
    }
  }

  // 2个具体的同事类
  // 房主类
  class HouseOwner extends Human {
    contact(message: string) {
      console.log(`房主 ${this.name} 发送消息 ${message}`);
      this.mediator.contact(message, this);
    }
    getMessage(message: string) {
      console.log(`房主 ${this.name} 收到消息 ${message}`);
    }
  }

  // 租客类
  class Tenant extends Human {
    contact(message: string) {
      console.log(`租客 ${this.name} 发送消息 ${message}`);
      this.mediator.contact(message, this);
    }
    getMessage(message: string) {
      console.log(`租客 ${this.name} 收到消息 ${message}`);
    }
  }

  // 具体中介者
  class ConcreteMediator extends Mediator {
    private tenant: Tenant;
    private houseOwner: HouseOwner;
    setTenant(tenant: Tenant) {
      this.tenant = tenant;
    }
    setHouseOwner(houseOwner: HouseOwner) {
      this.houseOwner = houseOwner;
    }
    // 由中介者来设置同事对象之间的联系关系
    contact(message: string, person: Human) {
      console.log('中介传递消息');
      if (person === this.houseOwner) {
        this.tenant.getMessage(message);
      } else {
        this.houseOwner.getMessage(message);
      }
    }
  }

  function mediatorDemo() {
    const mediator = new ConcreteMediator();
    const houseOwner = new HouseOwner('财大气粗的房叔', mediator);
    const tenant = new Tenant('远峰', mediator);
    // 向中介者注册成员
    mediator.setHouseOwner(houseOwner);
    mediator.setTenant(tenant);
    // 中介的成员只须要发送信息，而不须要关心具体接受者，联系关系都维护在了中介者中
    tenant.contact('我想租房');
    houseOwner.contact('我有房，你要租吗');
  }
复制代码

适用场景

一组对象以定义良好可是复杂的方式进行通讯，产生的相互依赖关系结构混乱且难以理解；
一个对象引用其余不少对象而且直接与这些对象通讯，致使难以复用该对象；
想经过一个中间类来封装多个类中的行为，而又不想生成太多的子类；

优势

简化了对象之间的关系，将系统的各个对象之间的相互关系进行封装，将各个同事类解耦，使系统成为松耦合系统；
使控制集中化。将交互的复杂性变为中介者的复杂性；
减小了子类的生成；
能够减小各同事类的设计与实现；

缺点

因为中介者对象封装了系统中对象之间的相互关系，致使其变得很是复杂，可能难以维护。

Memento（备忘录）

意图

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

结构

备忘录模式包含如下角色：

Originator（原发器）：它是一个普通类，能够建立一个备忘录，并存储它的当前内部状态，也可使用备忘录来恢复其内部状态，通常将须要保存内部状态的类设计为原发器。
Memento（备忘录)：存储原发器的内部状态，根据原发器来决定保存哪些内部状态。备忘录的设计通常能够参考原发器的设计，根据实际须要肯定备忘录类中的属性。须要注意的是，除了原发器自己与负责人类以外，备忘录对象不能直接供其余类使用，原发器的设计在不一样的编程语言中实现机制会有所不一样。
Caretaker（负责人）：负责人又称为管理者，它负责保存备忘录，可是不能对备忘录的内容进行操做或检查。在负责人类中能够存储一个或多个备忘录对象，它只负责存储对象，而不能修改对象，也无须知道对象的实现细节。

示例

案例：一个角色在画布中移动

// 备忘录类
class Memento {
  private x: number;
  private y: number;
  constructor(x: number, y: number) {
    this.x = x;
    this.y = y;
  }
  getX(): number {
    return this.x;
  }
  getY(): number {
    return this.y;
  }
}

// 原发器类
class Role {
  private x: number;
  private y: number;
  constructor(name: string, x: number, y: number) {
    this.x = x;
    this.y = y;
  }
  // 移动到新的位置
  moveTo(x: number, y: number): Memento {
    this.x = x;
    this.y = y;
    return this.save();
  }
  save(): Memento {
    return new Memento(this.x, this.y);
  }
  // 根据备忘录回退到某一个位置
  goBack(memento: Memento) {
    this.x = memento.getX();
    this.y = memento.getY();
  }
}

// 负责人，管理全部备忘录
class HistoryRecords {
  private records = [];
  // 添加备忘录
  add(record: Memento): void {
    this.records.push(record);
  }
  // 返回备忘录
  get(index: number): Memento {
    if (this.records[index]) {
      return this.records[index];
    }
    return null;
  }
  // 清除指定位置后面的备忘录
  cleanRecordsAfter(index: number): void {
    this.records.slice(0, index + 1);
  }
}

// 客户代码
function mementoDemo() {
  const role = new Role('卡通小人', 0, 0);
  const records = new HistoryRecords();
  // 记录初始位置
  records.add(role.save());
  // 移动时添加备忘录
  role.moveTo(10, 10);
  records.add(role.save());
  role.moveTo(20, 30);
  records.add(role.save());
  // 回退到初始位置
  const GO_BACK_STEP = 0;
  const firstMemento = records.get(GO_BACK_STEP);
  role.goBack(firstMemento);
  // 清除后面的记录
  records.cleanRecordsAfter(GO_BACK_STEP);
}
复制代码

适用场景

必须保存一个对象在某一个时刻的（部分）状态，这样之后须要时它才能恢复到先前的状态；
若是一个对象用接口来让其余对象直接获得内部状态，将会暴露对象的实现细节并破坏对象的封装性；

优势

保持封装边界。使用备忘录能够避免暴露一些只应由原发器管理却又必须存储在原发器以外的信息。
简化原发器。相对于把全部状态管理重任交给原发器，让客户管理他们请求的状态将会简化原发器，而且使得客户工做结束时无需通知原发器。

缺点

使用备忘录代价可能很高。若是原发器在生成备忘录时必须拷贝并存储大量的信息，或者客户很是频繁地建立备忘录和恢复原发器状态，可能致使很大的开销。除非封装和恢复状态的开销不打，不然该模式可能并不适合。
维护备忘录存在潜在代价。管理器负责删除它所维护的备忘录，然而管理器在运行过程当中不肯定会存入多少备忘录，所以可能原本很小的管理器，会产生大量的存储开销。

参考文档

本文介绍了5种对象行为型模式，对后续模式感兴趣的同窗能够关注专栏或者发送简历至'tao.qit####alibaba-inc.com'.replace('####', '@')，欢迎有志之士加入~

原文地址：github.com/ProtoTeam/b…

Typescript玩转设计模式 之 对象行为型模式（上）

Chain of Responsibility（职责链）

意图

结构

示例

适用场景

优势

缺点

相关模式

Command（命令）

意图

结构

示例

简单命令

可撤销命令

宏命令

适用场景

优势

缺点

相关模式

Iterator（迭代器）

意图

结构

示例

适用场景

优势

缺点

相关模式

Mediator（中介者）

意图

结构

示例

适用场景

优势

缺点

相关模式

Memento（备忘录）

意图

结构

示例

适用场景

优势

缺点

相关模式

参考文档

Typescript玩转设计模式之对象行为型模式（上）