24种设计模式--命令模式【Command Pattern】

　　今天讲命令模式，这个模式从名字上看就很简单，命令嘛，老大发命令，小兵执行就是了，确实是这个意思，但是更深化了，用模式来描述真实世界的命令情况。正在看这本书的你，我猜测分为两类：已经工作的和没有工作的，先说没有工作的，那你为啥要看这本书，为了以后工作呗，只要你参加工作，你肯定会待在项目组，那今天我们就以项目组为例子来讲述命令模式。

　　我是我们部门的项目经理，就是一个项目的头，在中国做项目，项目经理就是什么都要懂，什么都要管，做好了项目经理就能分到一杯羹，做不好都是你项目经理的责任，这个是绝对的，行政命令一压下来，那就一条道，做完做好！我们虽然是一个集团公司，但是我们部门是独立核算的，就是说呀，我们部门不仅仅为我们集团服务，还可以为其他甲方服务，赚取更多的外快，所以俺们的工资才能是中上等。记得一个比较小的项目，但是钱可不少，是做什么的呢？为一家旅行社建立一套内部管理系统，管理他的客户、旅游资源、票务以及内部管理，整体上类似一个小型的 ERP 系统，门店比较多，员工也比较多，但是需求比较明确，因为他们之前有一套自己购买的内部管理系统，这次变动部分模块基本上是翻版，而且旅行社有自己的IT 部门，比较好相处，都是技术人员，没有交流鸿沟嘛。

　　这个项目的成员分工也是采用了常规的分工方式，分为需求组（Requirement Group，简称 RG）、美工组（Page Group, 简称 PG）、代码组（我们内部还有一个比较优雅的名字：逻辑实现组，这里使用大家经常称呼的名称吧，英文缩写叫 Code Group，简称 CG），总共加上我这个项目经理正好十个人，刚开始的时候客户（也就是旅行社，甲方）还是很乐意和我们每个组探讨，比如和需求组讨论需求，和美工讨论页面，和代码组讨论实现，告诉他们修改这里，删除这里，增加这些等等，这是一种比较常见的甲乙方合作模式，甲方深入到乙方的项目开发中，我们把这个模式用类图表示一下：

　　这个类图很简单，客户和三个组都有交流，这也合情合理，那我们看看这个的实现，首先看抽象类，我们是面向接口或抽象类编程的嘛：

 1 package com.pattern.command;
 2
 3 /**
 4  * 项目组分成了三个组，每个组还是要接受增删改命令
 5  * @author http://www.cnblogs.com/initial-road/
 6  *
 7  */
 8 public abstract class Group {
 9
10     // 甲乙双方分开办公，你要和那个组讨论，你首先要找到这个组
11     public abstract void find();
12
13     // 被要求增加功能
14     public abstract void add();
15
16     // 被要求删除功能
17     public abstract void delete();
18
19     // 被要求修改功能
20     public abstract void change();
21
22     // 被要求给出所有的变更计划
23     public abstract void plan();
24 }

　　大家看抽象类中的每个方法，是不是每个都是一个命令？找到它，增加，删除，给我计划！是不是命令，这也就是命令模式中的命令接收者角色(Receiver) ，等会细讲。我们再看三个实现类，需求组最重要，没有需求你还设计个 P 呀，看 RequirmentGroup 类的实现：

 1 package com.pattern.command;
 2
 3 /**
 4  * 需求组的职责是和客户谈定需求，这个组的人应该都是业务领域专家
 5  * @author http://www.cnblogs.com/initial-road/
 6  *
 7  */
 8 public class RequirementGroup extends Group {
 9
10     // 客户要求增加一项需求
11     public void add() {
12         System.out.println("客户要求增加一项需求...");
13     }
14
15     // 客户要求修改一项需求
16     public void change() {
17         System.out.println("客户要求修改一项需求...");
18     }
19
20     // 客户要求删除一项需求
21     public void delete() {
22         System.out.println("客户要求删除一项需求...");
23     }
24
25     // 客户要求需求组过去和他们谈
26     public void find() {
27         System.out.println("找到需求组...");
28     }
29
30     // 客户要求出变更计划
31     public void plan() {
32         System.out.println("客户要求需求变更计划...");
33     }
34
35 }
36
37 需求组有了，我们再看美工组，美工组也很重要，是项目的脸面，客户最终接触到的还是界面，这个非常重要，看 PageGroup 的实现：
38
39 package com.pattern.command;
40
41 /**
42  * 美工组的职责是设计出一套漂亮、简单、便捷的界面
43  * @author http://www.cnblogs.com/initial-road/
44  *
45  */
46 public class PageGroup extends Group {
47
48     // 美工被要求增加一个页面
49     public void add() {
50         System.out.println("客户要求增加一个页面...");
51     }
52
53     // 客户要求对现有界面做修改
54     public void change() {
55         System.out.println("客户要求修改一个页面...");
56     }
57
58     // 甲方是老大，要求删除一些页面
59     public void delete() {
60         System.out.println("客户要求删除一个页面...");
61     }
62
63     // 首先这个美工组应该被找到吧，要不你跟谁谈？
64     public void find() {
65         System.out.println("找到美工组...");
66     }
67
68     // 所有的增删改那要给出计划呀
69     public void plan() {
70         System.out.println("客户要求页面变更计划...");
71     }
72
73 }

　　最后看代码组，这个组的成员一般都是比较闷骚型的，不多说话，但多做事儿，比较沉闷，这是这个组的典型特点，我们来看看这个 CodeGroup 类：

 1 package com.pattern.command;
 2
 3 /**
 4  * 代码组的职责是实现业务逻辑，当然包括数据库设计了
 5  * @author http://www.cnblogs.com/initial-road/
 6  *
 7  */
 8 public class CodeGroup extends Group {
 9
10     // 客户要求增加一项功能
11     public void add() {
12         System.out.println("客户要求增加一项功能...");
13     }
14
15     // 客户要求修改一项功能
16     public void change() {
17         System.out.println("客户要求删除一项功能...");
18     }
19
20     // 客户要求删除一项功能
21     public void delete() {
22         System.out.println("客户要求删除一项功能...");
23     }
24
25     // 客户要求代码组过去和他们谈
26     public void find() {
27         System.out.println("找到代码组...");
28     }
29
30     // 客户要求出变更计划
31     public void plan() {
32         System.out.println("客户要求代码变更计划...");
33     }
34
35 }

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

 1 package com.pattern.command;
 2
 3 /**
 4  * 客户就是甲方，给我们钱的一方，是老大
 5  * @author http://www.cnblogs.com/initial-road/
 6  *
 7  */
 8 public class Client {
 9
10     public static void main(String[] args) {
11
12         // 首先客户找到需求组说，过来谈需求，并修改
13         System.out.println("----------客户要求增加一个需求----------");
14         Group rg = new RequirementGroup();
15         // 找到需求组
16         rg.find();
17
18         // 增加一个需求
19         rg.add();
20
21         // 要求变更计划
22         rg.plan();
23
24     }
25
26 }

　　好的，客户的需求达到了，需求刚开始没考虑周全，增加需求是在所难免的嘛，理解理解。然后又过了段时间，客户说“界面多画了一个，过来谈谈”，于是：

 1 package com.pattern.command;
 2
 3 /**
 4  * 客户就是甲方，给我们钱的一方，是老大
 5  * @author http://www.cnblogs.com/initial-road/
 6  *
 7  */
 8 public class Client {
 9
10     public static void main(String[] args) {
11
12         // 首先客户找到美工组说，过来谈页面，并修改
13         System.out.println("----------客户要求删除一个页面----------");
14         Group pg = new PageGroup();
15         //找到美工组
16         pg.find();
17
18         // 删除一个页面
19         pg.delete();
20
21         // 要求变更计划
22         pg.plan();
23
24     }
25
26
27 }

　　好了，界面也谈过了，应该没什么大问题了吧。过了一天后，客户又让代码组过去，说是数据库设计问题，然后又叫美工过去，布置了一堆命令，这个我就不一一写了，大家应该能够体会到，你做过项目的话，这种体会更深，客户让修改你不修改？项目不想做了你!

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

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

　　我一听，好呀，这也正是我想要的，我项目组的兄弟们也已经受不了了，于是我改变了一下我的处理方式，看看类图：

　　类图中增加了不少，看着也比较清晰，比较简单的（Command 抽象类与 Group 抽象类是没有关联关系的，与 Group 的三个实现类是有关联关系，为了线条不交叉就直接画上父类有关系），增加的几个类说明如下：

　　Command 抽象类：客户发给我们的命令，定义三个工作组的成员变量，供子类使用；定义一个抽象方法execute，由子类来实现；

　　Invoker 实现类: 项目接头人， setComand 接受客户发给我我们的命令， action 方法是执行客户的命令（方法名写成是 action 是与 command 的execute 区分开，避免混淆）我们先看 Command 抽象类代码：

 1 package com.pattern.command;
 2
 3 /**
 4  * 命令的抽象类，我们把客户发出的命令定义成一个一个的对象
 5  * @author http://www.cnblogs.com/initial-road/
 6  *
 7  */
 8 public abstract class Command {
 9
10     // 把三个组都定义好，子类可以直接使用
11     // 需求组
12     protected RequirementGroup rg = new RequirementGroup();
13
14     // 美工组
15     protected PageGroup pg = new PageGroup();
16
17     // 代码组
18     protected CodeGroup cg = new CodeGroup();
19
20     // 只要一个方法，你要我做什么事情
21     public abstract void execute();
22 }
23
24 这个简单，看两个具体的实现类， 先看 AddRequeirementCommand 类, 这个类的作用就是增加一项需求。
25
26 package com.pattern.command;
27
28 /**
29  * 增加一项需求
30  * @author http://www.cnblogs.com/initial-road/
31  *
32  */
33 public class AddRequirementCommand extends Command {
34
35     // 执行增加一项需求的命令
36     public void execute() {
37         // 找到需求组
38         super.rg.find();
39
40         // 增加一份需求
41         super.rg.add();
42
43         // 观日出计划
44         super.rg.plan();
45
46     }
47
48 }
49
50 看删除一个页面的命令,DeletePageCommand 类：
51
52 package com.pattern.command;
53
54 /**
55  * 删除一个页面的命令
56  * @author http://www.cnblogs.com/initial-road/
57  *
58  */
59 public class DeletePageCommand extends Command {
60
61     // 执行删除一个页面的命令
62     public void execute() {
63         // 找到页面组
64         super.rg.find();
65
66         // 删除一个页面
67         super.rg.delete();
68
69         // 给出计划
70         super.rg.plan();
71     }
72
73 }

　　Command 抽象类还可以有很多的子类，比如增加一个功能命令（AddCodeCommand），删除一份需求命令（DeleteRequirementCommand）等等，这里就不用描述了，都很简单。我们再看我们的接头人，就是 Invoker 类的实现：

 1 package com.pattern.command.invoker;
 2
 3 import com.pattern.command.Command;
 4
 5 /**
 6  * 接头人的职责就是接收命令，并执行
 7  * @author zhangliang
 8  *
 9  */
10 public class Invoker {
11
12     // 什么命令
13     private Command command;
14
15     // 客户发出命令
16     public void setCommand(Command command){
17         this.command = command;
18     }
19
20     // 执行客户的命令
21     public void action(){
22         this.command.execute();
23     }
24
25 }
26
27 这个是更简单了，简单是简单，可以帮我们解决很多问题，我们再看一下客户提出变更的过程：
28
29 package com.pattern.command;
30
31 import com.pattern.command.invoker.Invoker;
32
33 /**
34  * 客户就是甲方，给我们钱的一方，是老大
35  * @author http://www.cnblogs.com/initial-road/
36  *
37  */
38 public class Client {
39
40     public static void main(String[] args) {
41
42         // 定义我们的接头人
43         // 接头人就是我小三
44         Invoker xiaoSan = new Invoker();
45
46         // 客户要求增加一项需求
47         System.out.println("----------客户要求增加一项需求----------");
48         // 客户给我们下命令来
49         Command command = new AddRequirementCommand();
50
51         // 接头人接收到命令
52         xiaoSan.setCommand(command);
53
54         // 接头人执行命令
55         xiaoSan.action();
56
57     }
58
59 }
60
61 那我们看看，如果客户要求删除一个页面，那我们的修改有多大呢？想想， Look:
62
63 package com.pattern.command;
64
65 import com.pattern.command.invoker.Invoker;
66
67 /**
68  * 客户就是甲方，给我们钱的一方，是老大
69  * @author http://www.cnblogs.com/initial-road/
70  *
71  */
72 public class Client {
73
74     public static void main(String[] args) {
75
76         // 定义我们的接头人
77         Invoker xiaoSan = new Invoker();
78
79         // 客户要求增加一项需求
80         System.out.println("----------客户要求删除一个页面----------");
81
82         // 客户给我们下命令来
83 //        Command command = new AddRequirementCommand();
84         Command command = new DeletePageCommand();
85
86         // 接头人接收到命令
87         xiaoSan.setCommand(command);
88
89         //接头人执行命令
90         xiaoSan.action();
91
92     }
93
94 }

　　看到上面注释代码了吗？就修改了这么多，就完成了一个命令的，是不是很简单，而且客户也不用知道到底要谁来修改，这个他不需要知道的，高内聚的要求体现出来了，这就是命令模式。

　　命令模式的通用类图如下：

　　在这个类图中，我们看到三个角色：

　　 Receiver 角色：这个就是干活的角色，命令传递到这里是应该被执行的，具体到上面我们的例子中就是Group 的三个实现类；

　　Command 角色：就是命令，需要我执行的所有命令都这里声明；

　　Invoker 角色：调用者，接收到命令，并执行命令，例子中我这里项目经理就是这个角色；

　　命令模式比较简单，但是在项目中使用是非常频繁的，封装性非常好，因为它把请求方（ Invoker）和执行方（Receiver）分开了，扩展性也有很好的保障。但是，命令模式也是有缺点的，你看 Command 的子类没有，那个如果我要写下去的可不是几个，而是几十个，这个类膨胀的非常多，这个就需要大家在项目中自己考虑使用了。

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

 1 package com.pattern.command;
 2
 3 /**
 4  * 增加一项需求
 5  * @author http://www.cnblogs.com/initial-road/
 6  *
 7  */
 8 public class AddRequirementCommand extends Command {
 9
10     // 执行增加一项需求的命令
11     public void execute() {
12         // 找到需求组
13         super.rg.find();
14
15         // 增加一份需求
16         super.rg.add();
17
18         // 页面也要增加
19         super.pg.add();
20
21         // 功能也要增加
22         super.cg.add();
23
24         // 观日出计划
25         super.rg.plan();
26
27     }
28
29 }

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

转载于:https://www.cnblogs.com/initial-road/p/command_pattern.html

24种设计模式--命令模式【Command Pattern】相关推荐

设计模式:命令模式(Command Pattern)
命令模式(Command Pattern): 在软件设计中,我们经常需要向某些对象发送请求,但是并不知道请求的接受者是谁,也不知道请求的操作是哪个. 我们只需在程序运行时指定具体的请求接受者即可,此时 ...
设计模式 - 命令模式(command pattern) 撤销(undo) 具体解释
命令模式(command pattern) 撤销(undo) 详细解释本文地址: http://blog.csdn.net/caroline_wendy 參考命令模式: http://blog.cs ...
解读设计模式----命令模式(Command Pattern)
***本文与作者原文有一定的偏差,其中加入了一部分是个人看法,详细请查看作者原文.*** 原文连接http://www.dofactory.com/Patterns/PatternCommand.as ...
乐在其中设计模式(C#) - 命令模式(Command Pattern)
原文:乐在其中设计模式(C#) - 命令模式(Command Pattern) [索引页] [源码下载] 乐在其中设计模式(C#) - 命令模式(Command Pattern) 作者:webabcd ...
设计模式系列3-----C++实现命令模式(Command Pattern)
什么是命令模式? GoF的书的定义为:"Command pattern encapsulate request as an object, thereby letting you param ...
32命令模式(Command Pattern)
耦合与变化: 耦合是软件不能抵御变化灾难的根本性原因.不仅实体对象与实体对象之间存在耦合关系,实体对象与行为操作之间也存在耦合关系. ...
23种设计模式-命令模式《三国大阅兵》
对于许久不用的东西,容易忘记.百度许久,也未能找到自己所要. 从今日起,有些东西就记载下来,不仅方便自己,希望能帮到他人吧! 在面向对象程式设计的范畴中,命令模式(Command Pattern)是一 ...
C++设计模式--命令模式(Command)
概述命令模式的结构很简单,但是对于消除代码间的耦合却有着重要的影响.命令模式就是一个函数对象:一个作为对象的函数.通过将函数封装为对象,就能够以参数的形式将其传递给其他函数或者对象,告诉它们在旅行请 ...
命令模式(Command pattern)及代码实现
模式定义: 将客户端的请求封装成一个对象(这个对象就是命令对象),使请求的发送者和请求的接收者进行责任分离解耦, 这样两者只通过命令进行交互;发送者不关心请求的具体实现细节, 接收者 ...

24种设计模式--命令模式【Command Pattern】

24种设计模式--命令模式【Command Pattern】相关推荐

最新文章

热门文章