命令模式
一. 定义
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志，以及支持可撤销的操作。
二. 模式的引入（项目组开发为例）
解决的问题
在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
项目的成员分为需求组（Requirement Group，简称RG）、美工组（Page Group,简称PG）、代码组（Code Group，简称CG），总共加上项目经理正好十个人，刚开始的时候甲方还是很乐意和我们每个组探讨，比如和需求组讨论需求，和美工讨论页面，和代码组讨论实现，告诉他们修改这里，删除这里，增加这些等等，这是一种比较常见的甲乙方合作模式，甲方深入到乙方的项目开发中，我们把这个模式用类图表示一下：
项目组抽象
public abstract class Group { // 甲乙双方分开办公，你要和那个组讨论，你首先要找到这个组 public abstract void find(); // 被要求增加功能 public abstract void add(); // 被要求删除功能 public abstract void delete(); // 被要求修改功能 public abstract void change(); // 被要求给出所有的变更计划 public abstract void plan();} 需求组
public class RequirementGroup extends Group { // 客户要求需求组过去和他们谈 public void find() { System.out.println("找到需求组..."); } // 客户要求增加一项需求 public void add() { System.out.println("客户要求增加一项需求..."); } // 客户要求修改一项需求 public void change() { System.out.println("客户要求修改一项需求..."); } // 客户要求删除一项需求 public void delete() { System.out.println("客户要求删除一项需求..."); } // 客户要求出变更计划 public void plan() { System.out.println("客户要求需求变更计划..."); }} 代码组
public class CodeGroup extends Group { // 客户要求代码组过去和他们谈 public void find() { System.out.println("找到代码组..."); } // 客户要求增加一项功能 public void add() { System.out.println("客户要求增加一项功能..."); } // 客户要求修改一项功能 public void change() { System.out.println("客户要求修改一项功能..."); } // 客户要求删除一项功能 public void delete() { System.out.println("客户要求删除一项功能..."); } // 客户要求出变更计划 public void plan() { System.out.println("客户要求代码变更计划..."); }} 美工组
public class PageGroup extends Group { // 首先这个美工组应该被找到吧，要不你跟谁谈？ public void find() { System.out.println("找到美工组..."); } // 美工被要求增加一个页面 public void add() { System.out.println("客户要求增加一个页面..."); } // 客户要求对现有界面做修改 public void change() { System.out.println("客户要求修改一个页面..."); } // 甲方是老大，要求删除一些页面 public void delete() { System.out.println("客户要求删除一个页面..."); } // 所有的增删改那要给出计划呀 public void plan() { System.out.println("客户要求页面变更计划..."); }} 整个项目的三个支柱都已经产生了，那看客户怎么和我们谈。客户刚刚开始给了我们一份他们自己写的一份需求，还是比较完整的，需求组根据这份需求写了一份分析说明书，客户一看要增加点需求
public class Client { public static void main(String[] args) { // 首先客户找到需求组说，过来谈需求，并修改 System.out.println("-------------客户要求增加一个需求-----------------"); Group rg = new RequirementGroup(); // 找到需求组 rg.find(); // 增加一个需求 rg.add(); // 要求变更计划 rg.plan(); }} 然后又过了段时间，客户说“界面多画了一个，找美工组过来谈谈”
public class Client { public static void main(String[] args) { // 首先客户找到美工组说，过来谈页面，并修改 System.out.println("-------------客户要求删除一个页面-----------------"); Group pg = new PageGroup(); // 找到美工组 pg.find(); // 删除一个页面 pg.delete(); // 要求变更计划 pg.plan(); }} 问题出现了，每次都是叫一个组去，布置个任务，然后出计划，次次都这样，如果让你当甲方也就是客户，你烦不烦？而且这种方式很容易出错误呀，客户把美工叫过去了，要删除，可美工说需求是这么写的，然后客户又命令需求组过去，一次次的折腾，客户也烦躁了，于是直接抓住项目经理说：
“我不管你们内部怎么安排，你就给我找个接头人，我告诉他怎么做，删除页面了，增加功能了，你们内部怎么处理，我就告诉他我要干什么就成了…”
我们把客户发出的命令定义成一个一个的对象
抽象命令（本例中直接把接收者作为命令接口的常量了，一般命令接口只有execute方法）
/** * 命令的抽象类 */public abstract class Command { // 把三个组都定义好，子类可以直接使用 protected RequirementGroup rg = new RequirementGroup(); // 需求组 protected PageGroup pg = new PageGroup(); // 美工组 protected CodeGroup cg = new CodeGroup(); // 代码组; // 只要一个方法，你要我做什么事情 public abstract void execute();} DeletePageCommand 删除页面命令
/** * 删除一个页面的命令 */public class DeletePageCommand extends Command { // 执行删除一个页面的命令 public void execute() { // 找到页面组 super.pg.find(); // 删除一个页面 super.pg.delete(); // 给出计划 super.pg.plan(); }} AddRequirementCommand 增加需求命令
/** * 增加一项需求 */public class AddRequirementCommand extends Command { // 执行增加一项需求的命令 public void execute() { // 找到需求组 super.rg.find(); // 增加一份需求 super.rg.add(); // 给出计划 super.rg.plan(); }} Command抽象类还可以有很多的子类，比如增加一个功能命令（AddCodeCommand），删除一份需求命令（DeleteRequirementCommand）等等，这里就不用描述了，都很简单。
Invoker 项目经理
/**接头人的职责就是接收命令，并执行 */public class Invoker { // 什么命令 private Command command; // 客户发出命令 public void setCommand(Command command) { this.command = command; } // 执行客户的命令 public void action() { this.command.execute(); }} Client
public class Client { public static void main(String[] args) { // 定义我们的接头人 项目经理 Invoker manager = new Invoker(); // 接头人就是项目经理 // 客户要求增加一项需求 System.out.println("-------------客户要求增加一项需求-----------------"); // 客户给我们下命令来 Command command = new AddRequirementCommand(); // 接头人接收到命令 manager.setCommand(command); // 接头人执行命令 manager.action(); }} 如果客户要求删除一个页面，只需把上面的 command = new AddRequirementCommand改成DeletePageCommand即可。
public class Client { public static void main(String[] args) { // 定义我们的接头人 项目经理 Invoker manager = new Invoker(); // 接头人就是项目经理 // 客户要求增加一项需求 System.out.println("-------------客户要求增加一项需求-----------------"); // 客户给我们下命令来 Command command = new DeletePageCommand(); // 接头人接收到命令 manager.setCommand(command); // 接头人执行命令 manager.action(); }} 组合命令
客户要求增加一项需求，那是不是页面也增加，同时功能也要增加呢？如果不使用命令模式，客户就需要先找需求组，然后找美工组，然后找代码组，这个…，你想让客户跳楼呀！使用命令模式后，客户只管发命令模式，你增加一项需求，没问题，我内部调动三个组通力合作，然后反馈你结果，这也正是客户需要的，那这个要怎么修改呢？想想看，很简单的，在AddRequirementCommand类的execute方法中增加对PageGroup和CodePage的调用就成了，修改后的代码如下：
public class AddRequirementCommand extends Command { // 执行增加一项需求的命令 public void execute() { // 找到需求组 super.rg.find(); // 增加一份需求 super.rg.add(); // 页面也要增加 super.pg.add(); // 功能也要增加 super.cg.add(); // 给出计划 super.rg.plan(); }} 撤销命令
命令模式做了一层非常好的封装。那还有一个问题需要大家考虑：客户发出命令，那要是撤回怎么办？就类似你使用Ctl+Z组合键（undo功能），发出一个命令，在没有执行或执行后撤回（执行后撤回是状态变更）该怎么实现呢?想想看，简单，非常简单，undo也是一个命令嘛！
public abstract class Group { // 甲乙双方分开办公，你要和那个组讨论，你首先要找到这个组 public abstract void find(); // 被要求增加功能 public abstract void add(); // 被要求删除功能 public abstract void delete(); // 被要求修改功能 public abstract void change(); // 被要求给出所有的变更计划 public abstract void plan(); // 每个接收者都要对直接执行的任务可以回滚 public void rollback() { //根据日志进行回滚 }} 三. 模式解读
3.1 命令模式的类图
3.2包含的角色
- 抽象命令（Command）：定义命令的接口，声明执行的方法。
- 具体命令（ConcreteCommand）：具体命令，实现要执行的方法，它通常是“虚”的实现；通常会有接收者，并调用接收者的功能来完成命令要执行的操作。
- 接收者（Receiver）：真正执行命令的对象。任何类都可能成为一个接收者，只要能实现命令要求实现的相应功能。
- 调用者（Invoker）：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
- 客户端（Client）：命令由客户端来创建，并设置命令的接收者。
3.3 命令模式的实现代码
Receiver
public abstract class Receiver { //每个接收者处理的业务 public abstract void action(); } ReceiverA
public class ReceiverA extends Receiver { public void action() { System.out.println("接收者A执行命令"); }} ReceiverB
public class ReceiverB extends Receiver{ public void action() { System.out.println("接收者B执行命令"); }} Command
public interface Command { public abstract void execute();} CommandImplA
public class CommandImplA implements Command { private Receiver receiver; public CommandImplA(Receiver receiver) { this.receiver=receiver; } public void execute() { receiver.action(); }} CommandImplB
public class CommandImplB implements Command { private Receiver receiver; public CommandImplB(Receiver receiver) { this.receiver=receiver; } public void execute() { receiver.action(); }} Invoker
public class Invoker { private Command command; public void setCommand(Command command) { this.command = command; } public void execute() { command.execute(); }} Client
public class Client{ public static void main(String[] args) { Receiver rec = new ReceiverA(); Command cmd = new CommandImplA(rec); Invoker i = new Invoker(); i.setCommand(cmd); i.execute(); rec=new ReceiverB(); cmd=new CommandImplB(rec); i.setCommand(cmd); i.execute(); }} 执行结果
| 接收者A执行命令 接收者B执行命令 |
3.4 模式分析
- 本质：对命令进行封装，将发出命令与执行命令的责任分开。
- 每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。
- 请求方和接收方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。
- 使请求本身成为一个对象，这个对象和其它对象一样可以被存储和传递。
- 命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。
四. 模式总结
4.1 优点
- 解除了请求者与实现者之间的耦合，降低了系统的耦合度。
- 对请求排队或记录请求日志，支持撤销操作。
- 可以容易地设计一个组合命令。
- 新命令可以容易地加入到系统中。
4.2 缺点
- 因为针对每一个命令都需要设计一个具体命令类，使用命令模式可能会导致系统有过多的具体命令类。
4.3 适用场景
- 当需要对行为进行“记录、撤销/重做”等处理时。
- 系统需要将请求者和接收者解耦，使得调用者和接收者不直接交互。
- 系统需要在不同时间指定请求、请求排队和执行请求。
- 系统需要将一组操作组合在一起，即支持宏命令。
参考： 设计模式之禅