设计模式(12)——命令模式

命令模式

一. 定义

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

二. 模式的引入(项目组开发为例

解决的问题

在软件系统中,行为请求者与行为实现者通常是一种紧耦合的关系,但某些场合,比如需要对行为进行记录、撤销或重做、事务等处理时,这种无法抵御变化的紧耦合的设计就不太合适。

 

项目的成员分为需求组(Requirement Group,简称RG)、美工组(Page Group,简称PG)、代码组(Code Group,简称CG),总共加上项目经理正好十个人,刚开始的时候甲方还是很乐意和我们每个组探讨,比如和需求组讨论需求,和美工讨论页面,和代码组讨论实现,告诉他们修改这里,删除这里,增加这些等等,这是一种比较常见的甲乙方合作模式,甲方深入到乙方的项目开发中,我们把这个模式用类图表示一下:

项目组抽象

[java]  view plain copy print ?
  1. public abstract class Group {  
  2.     // 甲乙双方分开办公,你要和那个组讨论,你首先要找到这个组  
  3.     public abstract void find();  
  4.   
  5.     // 被要求增加功能  
  6.     public abstract void add();  
  7.   
  8.     // 被要求删除功能  
  9.     public abstract void delete();  
  10.   
  11.     // 被要求修改功能  
  12.     public abstract void change();  
  13.   
  14.     // 被要求给出所有的变更计划  
  15.     public abstract void plan();  
  16. }  

需求组

[html]  view plain copy print ?
  1. public class RequirementGroup extends Group {  
  2.     // 客户要求需求组过去和他们谈  
  3.     public void find() {  
  4.         System.out.println("找到需求组...");  
  5.     }  
  6.   
  7.     // 客户要求增加一项需求  
  8.     public void add() {  
  9.         System.out.println("客户要求增加一项需求...");  
  10.     }  
  11.   
  12.     // 客户要求修改一项需求  
  13.     public void change() {  
  14.         System.out.println("客户要求修改一项需求...");  
  15.     }  
  16.   
  17.     // 客户要求删除一项需求  
  18.     public void delete() {  
  19.         System.out.println("客户要求删除一项需求...");  
  20.     }  
  21.   
  22.     // 客户要求出变更计划  
  23.     public void plan() {  
  24.         System.out.println("客户要求需求变更计划...");  
  25.   
  26.     }  
  27. }  

代码组

[java]  view plain copy print ?
  1. public class CodeGroup extends Group {  
  2.     // 客户要求代码组过去和他们谈  
  3.     public void find() {  
  4.         System.out.println("找到代码组...");  
  5.     }  
  6.   
  7.     // 客户要求增加一项功能  
  8.     public void add() {  
  9.         System.out.println("客户要求增加一项功能...");  
  10.     }  
  11.   
  12.     // 客户要求修改一项功能  
  13.     public void change() {  
  14.         System.out.println("客户要求修改一项功能...");  
  15.     }  
  16.   
  17.     // 客户要求删除一项功能  
  18.     public void delete() {  
  19.         System.out.println("客户要求删除一项功能...");  
  20.     }  
  21.   
  22.     // 客户要求出变更计划  
  23.     public void plan() {  
  24.         System.out.println("客户要求代码变更计划...");  
  25.     }  
  26. }  

美工组

[java]  view plain copy print ?
  1. public class PageGroup extends Group {  
  2.     // 首先这个美工组应该被找到吧,要不你跟谁谈?  
  3.     public void find() {  
  4.         System.out.println("找到美工组...");  
  5.     }  
  6.   
  7.     // 美工被要求增加一个页面  
  8.     public void add() {  
  9.         System.out.println("客户要求增加一个页面...");  
  10.     }  
  11.   
  12.     // 客户要求对现有界面做修改  
  13.     public void change() {  
  14.         System.out.println("客户要求修改一个页面...");  
  15.     }  
  16.   
  17.     // 甲方是老大,要求删除一些页面  
  18.     public void delete() {  
  19.         System.out.println("客户要求删除一个页面...");  
  20.     }  
  21.   
  22.     // 所有的增删改那要给出计划呀  
  23.     public void plan() {  
  24.         System.out.println("客户要求页面变更计划...");  
  25.     }  
  26. }  

整个项目的三个支柱都已经产生了,那看客户怎么和我们谈。客户刚刚开始给了我们一份他们自己写的一份需求,还是比较完整的,需求组根据这份需求写了一份分析说明书,客户一看要增加点需求

[java]  view plain copy print ?
  1. public class Client {  
  2.     public static void main(String[] args) {  
  3.         // 首先客户找到需求组说,过来谈需求,并修改  
  4.         System.out.println("-------------客户要求增加一个需求-----------------");  
  5.         Group rg = new RequirementGroup();  
  6.         // 找到需求组  
  7.         rg.find();  
  8.         // 增加一个需求  
  9.         rg.add();  
  10.         // 要求变更计划  
  11.         rg.plan();  
  12.     }  
  13. }  

然后又过了段时间,客户说“界面多画了一个,找美工组过来谈谈”

[java]  view plain copy print ?
  1. public class Client {  
  2.     public static void main(String[] args) {  
  3.         // 首先客户找到美工组说,过来谈页面,并修改  
  4.         System.out.println("-------------客户要求删除一个页面-----------------");  
  5.         Group pg = new PageGroup();  
  6.         // 找到美工组  
  7.         pg.find();  
  8.         // 删除一个页面  
  9.         pg.delete();  
  10.         // 要求变更计划  
  11.         pg.plan();  
  12.     }  
  13. }  

问题出现了,每次都是叫一个组去,布置个任务,然后出计划,次次都这样,如果让你当甲方也就是客户,你烦不烦?而且这种方式很容易出错误呀,客户把美工叫过去了,要删除,可美工说需求是这么写的,然后客户又命令需求组过去,一次次的折腾,客户也烦躁了,于是直接抓住项目经理说:

“我不管你们内部怎么安排,你就给我找个接头人,我告诉他怎么做,删除页面了,增加功能了,你们内部怎么处理,我就告诉他我要干什么就成了

我们把客户发出的命令定义成一个一个的对象

抽象命令(本例中直接把接收者作为命令接口的常量了,一般命令接口只有execute方法)

[java]  view plain copy print ?
  1. /** 
  2.  * 命令的抽象类 */  
  3. public abstract class Command {  
  4.     // 把三个组都定义好,子类可以直接使用  
  5.     protected RequirementGroup rg = new RequirementGroup(); // 需求组  
  6.     protected PageGroup pg = new PageGroup(); // 美工组  
  7.     protected CodeGroup cg = new CodeGroup(); // 代码组;  
  8.       
  9.     // 只要一个方法,你要我做什么事情  
  10.     public abstract void execute();  
  11. }  

 DeletePageCommand  删除页面命令

[java]  view plain copy print ?
  1. /** 
  2.  * 删除一个页面的命令 
  3.  */  
  4. public class DeletePageCommand extends Command {  
  5.     // 执行删除一个页面的命令  
  6.     public void execute() {  
  7.         // 找到页面组  
  8.         super.pg.find();  
  9.         // 删除一个页面  
  10.         super.pg.delete();  
  11.         // 给出计划  
  12.         super.pg.plan();  
  13.     }  
  14. }  

AddRequirementCommand 增加需求命令

[java]  view plain copy print ?
  1. /** 
  2.  * 增加一项需求 
  3.  */  
  4. public class AddRequirementCommand extends Command {  
  5.     // 执行增加一项需求的命令  
  6.     public void execute() {  
  7.         // 找到需求组  
  8.         super.rg.find();  
  9.         // 增加一份需求  
  10.         super.rg.add();  
  11.         // 给出计划  
  12.         super.rg.plan();  
  13.     }  
  14. }  

Command抽象类还可以有很多的子类,比如增加一个功能命令(AddCodeCommand),删除一份需求命令(DeleteRequirementCommand)等等,这里就不用描述了,都很简单。

Invoker  项目经理

[java]  view plain copy print ?
  1. /** 
  2. 接头人的职责就是接收命令,并执行 
  3.  */  
  4. public class Invoker {  
  5.     // 什么命令  
  6.     private Command command;  
  7.   
  8.     // 客户发出命令  
  9.     public void setCommand(Command command) {  
  10.         this.command = command;  
  11.     }  
  12.   
  13.     // 执行客户的命令  
  14.     public void action() {  
  15.         this.command.execute();  
  16.     }  
  17.   
  18. }  

Client

[java]  view plain copy print ?
  1. public class Client {  
  2.     public static void main(String[] args) {  
  3.         // 定义我们的接头人 项目经理  
  4.         Invoker manager = new Invoker(); // 接头人就是项目经理  
  5.         // 客户要求增加一项需求  
  6.         System.out.println("-------------客户要求增加一项需求-----------------");  
  7.         // 客户给我们下命令来  
  8.         Command command = new AddRequirementCommand();  
  9.         // 接头人接收到命令  
  10.         manager.setCommand(command);  
  11.         // 接头人执行命令  
  12.         manager.action();  
  13.     }  
  14. }  

如果客户要求删除一个页面,只需把上面的 command = new AddRequirementCommand改成DeletePageCommand即可。

[java]  view plain copy print ?
  1. public class Client {  
  2.     public static void main(String[] args) {  
  3.         // 定义我们的接头人 项目经理  
  4.         Invoker manager = new Invoker(); // 接头人就是项目经理  
  5.         // 客户要求增加一项需求  
  6.         System.out.println("-------------客户要求增加一项需求-----------------");  
  7.         // 客户给我们下命令来  
  8.         Command command = new DeletePageCommand();  
  9.         // 接头人接收到命令  
  10.         manager.setCommand(command);  
  11.         // 接头人执行命令  
  12.         manager.action();  
  13.     }  
  14. }  

组合命令

客户要求增加一项需求,那是不是页面也增加,同时功能也要增加呢?如果不使用命令模式,客户就需要先找需求组,然后找美工组,然后找代码组,这个,你想让客户跳楼呀!使用命令模式后,客户只管发命令模式,你增加一项需求,没问题,我内部调动三个组通力合作,然后反馈你结果,这也正是客户需要的,那这个要怎么修改呢?想想看,很简单的,在AddRequirementCommand类的execute方法中增加对PageGroupCodePage的调用就成了,修改后的代码如下:

[html]  view plain copy print ?
  1. public class AddRequirementCommand extends Command {  
  2.     // 执行增加一项需求的命令  
  3.     public void execute() {  
  4.         // 找到需求组  
  5.         super.rg.find();  
  6.         // 增加一份需求  
  7.         super.rg.add();  
  8.         // 页面也要增加  
  9.         super.pg.add();  
  10.         // 功能也要增加  
  11.         super.cg.add();  
  12.         // 给出计划  
  13.         super.rg.plan();  
  14.     }  
  15. }  

撤销命令

命令模式做了一层非常好的封装。那还有一个问题需要大家考虑:客户发出命令,那要是撤回怎么办?就类似你使用Ctl+Z组合键(undo功能),发出一个命令,在没有执行或执行后撤回(执行后撤回是状态变更)该怎么实现呢?想想看,简单,非常简单,undo也是一个命令嘛!

[java]  view plain copy print ?
  1. public abstract class Group {  
  2.     // 甲乙双方分开办公,你要和那个组讨论,你首先要找到这个组  
  3.     public abstract void find();  
  4.   
  5.     // 被要求增加功能  
  6.     public abstract void add();  
  7.   
  8.     // 被要求删除功能  
  9.     public abstract void delete();  
  10.   
  11.     // 被要求修改功能  
  12.     public abstract void change();  
  13.   
  14.     // 被要求给出所有的变更计划  
  15.     public abstract void plan();  
  16.       
  17.     // 每个接收者都要对直接执行的任务可以回滚  
  18.     public void rollback()  
  19.     {  
  20.         //根据日志进行回滚  
  21.     }  
  22. }  

三. 模式解读

3.1 命令模式的类图

3.2包含的角色

  1. 抽象命令(Command):定义命令的接口,声明执行的方法。
  2. 具体命令(ConcreteCommand):具体命令,实现要执行的方法,它通常是的实现;通常会有接收者,并调用接收者的功能来完成命令要执行的操作。
  3. 接收者(Receiver):真正执行命令的对象。任何类都可能成为一个接收者,只要能实现命令要求实现的相应功能。
  4. 调用者(Invoker):要求命令对象执行请求,通常会持有命令对象,可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方,也就是说相当于使用命令对象的入口。
  5. 客户端(Client):命令由客户端来创建,并设置命令的接收者。

3.3 命令模式的实现代码

Receiver

[java]  view plain copy print ?
  1. public abstract class Receiver  {  
  2.   
  3.     //每个接收者处理的业务  
  4.     public abstract void  action();  
  5.     }  

ReceiverA

[html]  view plain copy print ?
  1. public class ReceiverA extends Receiver {  
  2.   
  3.     public void action() {  
  4.         System.out.println("接收者A执行命令");  
  5.     }  
  6. }  

ReceiverB

[html]  view plain copy print ?
  1. public class ReceiverB extends Receiver{  
  2.   
  3.     public void action() {  
  4.         System.out.println("接收者B执行命令");  
  5.     }  
  6. }  

Command

[html]  view plain copy print ?
  1. public interface Command {  
  2.   
  3.     public abstract void execute();  
  4. }  

CommandImplA

[java]  view plain copy print ?
  1. public class CommandImplA implements Command {  
  2.   
  3.     private Receiver receiver;  
  4.   
  5.     public CommandImplA(Receiver receiver) {  
  6.       this.receiver=receiver;  
  7.     }  
  8.   
  9.     public void execute() {  
  10.         receiver.action();  
  11.     }  
  12. }  

CommandImplB

[java]  view plain copy print ?
  1. public class CommandImplB implements Command {  
  2.   
  3.     private Receiver receiver;  
  4.   
  5.     public CommandImplB(Receiver receiver) {  
  6.       this.receiver=receiver;  
  7.     }  
  8.   
  9.     public void execute() {  
  10.         receiver.action();  
  11.     }  
  12. }  

Invoker

[java]  view plain copy print ?
  1. public class Invoker {  
  2.   
  3.     private Command command;  
  4.   
  5.     public void setCommand(Command command) {  
  6.         this.command = command;  
  7.     }  
  8.   
  9.     public void execute() {  
  10.         command.execute();  
  11.     }  
  12. }  

Client

[java]  view plain copy print ?
  1. public class Client  
  2. {  
  3.   
  4.     public static void main(String[] args) {  
  5.   
  6.         Receiver rec = new ReceiverA();  
  7.         Command cmd = new CommandImplA(rec);  
  8.         Invoker i = new Invoker();  
  9.         i.setCommand(cmd);  
  10.         i.execute();  
  11.   
  12.         rec=new ReceiverB();  
  13.         cmd=new CommandImplB(rec);  
  14.         i.setCommand(cmd);  
  15.         i.execute();  
  16.     }  
  17. }  

执行结果

接收者A执行命令
接收者B执行命令

3.4 模式分析

  1. 本质:对命令进行封装,将发出命令与执行命令的责任分开。
  2. 每一个命令都是一个操作:请求的一方发出请求,要求执行一个操作;接收的一方收到请求,并执行操作。
  3. 请求方和接收方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否被执行、何时被执行,以及是怎么被执行的
  4. 使请求本身成为一个对象,这个对象和其它对象一样可以被存储和传递。
  5. 命令模式的关键在于引入了抽象命令接口,且发送者针对抽象命令接口编程,只有实现了抽象命令接口的具体命令才能与接收者相关联。 

四. 模式总结

4.1 优点

  1. 解除了请求者与实现者之间的耦合,降低了系统的耦合度。
  2. 对请求排队或记录请求日志,支持撤销操作。
  3. 可以容易地设计一个组合命令。
  4. 新命令可以容易地加入到系统中。

4.2 缺点

  • 因为针对每一个命令都需要设计一个具体命令类,使用命令模式可能会导致系统有过多的具体命令类。

4.3 适用场景

  • 当需要对行为进行记录、撤销/重做等处理时。
  • 系统需要将请求者和接收者解耦,使得调用者和接收者不直接交互。
  • 系统需要在不同时间指定请求、请求排队和执行请求。
  • 系统需要将一组操作组合在一起,即支持宏命令。

参考: 设计模式之禅

                    http://www.cnblogs.com/wangjq/archive/2012/07/11/2585930.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值