设计模式(12)---->命令模式
命令模式
一. 定义
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志，以及支持可撤销的操作。
二. 模式的引入（项目组开发为例）
解决的问题
在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
项目的成员分为需求组（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执行命令 |
3.4 模式分析
-
本质：对命令进行封装，将发出命令与执行命令的责任分开。
-
每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。
-
请求方和接收方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。
-
使请求本身成为一个对象，这个对象和其它对象一样可以被存储和传递。
-
命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。
四. 模式总结
4.1 优点
-
解除了请求者与实现者之间的耦合，降低了系统的耦合度。
-
对请求排队或记录请求日志，支持撤销操作。
-
可以容易地设计一个组合命令。
-
新命令可以容易地加入到系统中。
4.2 缺点
-
因为针对每一个命令都需要设计一个具体命令类，使用命令模式可能会导致系统有过多的具体命令类。
4.3 适用场景
-
当需要对行为进行“记录、撤销/重做”等处理时。
-
系统需要将请求者和接收者解耦，使得调用者和接收者不直接交互。
-
系统需要在不同时间指定请求、请求排队和执行请求。
-
系统需要将一组操作组合在一起，即支持宏命令。
参考： 设计模式之禅
http://www.cnblogs.com/wangjq/archive/2012/07/11/2585930.html
