命令模式

• 命令模式
  • 1 模式的定义
  • 2 模式的结构
    • 2.1 结构图
    • 2.2 参与者
  • 3 模式分析
    • 3.1 优点
    • 3.2 缺点
  • 4 适用环境
  • 5 实现方式
  • 6 代码实现
  • 参考

本文介绍命令模式定义、结构、特点、适用场景、代码实现。

命令模式

1 模式的定义

命令模式(Command Pattern)：将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。

2 模式的结构

2.1 结构图

2.2 参与者

1. 发送者（Sender）——亦称“触发者（Invoker）”——类负责对请求进行初始化，其中必须包含一个成员变量来存储对于命令对象的引用。发送者触发命令，而不向接收者直接发送请求。注意，发送者并不负责创建命令对象：它通常会通过构造函数从客户端处获得预先生成的命令。
2. 命令（Command）接口通常仅声明一个执行命令的方法。
3. 具体命令（Concrete Commands）会实现各种类型的请求。具体命令自身并不完成工作，而是会将调用委派给一个业务逻辑对象。但为了简化代码，这些类可以进行合并。接收对象执行方法所需的参数可以声明为具体命令的成员变量。你可以将命令对象设为不可变，仅允许通过构造函数对这些成员变量进行初始化。
4. 接收者（Receiver）类包含部分业务逻辑。几乎任何对象都可以作为接收者。绝大部分命令只处理如何将请求传递到接收者的细节，接收者自己会完成实际的工作。

3 模式分析

3.1 优点

• 单一职责原则。你可以解耦触发和执行操作的类。
• 开闭原则。你可以在不修改已有客户端代码的情况下在程序中创建新的命令。
• 你可以实现撤销和恢复功能。
• 你可以实现操作的延迟执行。
• 你可以将一组简单命令组合成一个复杂命令。

3.2 缺点

• 使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个命令都需要设计一个具体命令类，因此某些系统可能需要大量具体命令类，这将影响命令模式的使用。

4 适用环境

• 系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。
• 系统需要在不同的时间指定请求、将请求排队和执行请求。
• 系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
• 系统需要将一组操作组合在一起，即支持宏命令

5 实现方式

1. 声明仅有一个执行方法的命令接口。
2. 抽取请求并使之成为实现命令接口的具体命令类。每个类都必须有一组成员变量来保存请求参数和对于实际接收者对象的引用。所有这些变量的数值都必须通过命令构造函数进行初始化。
3. 找到担任发送者职责的类。在这些类中添加保存命令的成员变量。发送者只能通过命令接口与其命令进行交互。发送者自身通常并不创建命令对象，而是通过客户端代码获取。
4. 修改发送者使其执行命令，而非直接将请求发送给接收者。
5. 客户端必须按照以下顺序来初始化对象：
   1. 创建接收者。
   2. 创建命令，如有需要可将其关联至接收者。
   3. 创建发送者并将其与特定命令关联。

6 代码实现

https://github.com/august295/DesignPatternCode

参考

[1] https://design-patterns.readthedocs.io/zh_CN/latest/behavioral_patterns/command.html

[2] https://refactoringguru.cn/design-patterns/command