命令模式【Command Pattern 】
2016-01-04 19:05
232 查看
幸福就是回来看书,看自己想看的书。
博客地址 http://blog.csdn.net/ftx2540993425
下面横线以上内容是借鉴别人的,为了表达对作者的敬意,不做不恰当的修改,我个人的总结在后面。好的东西
今天讲命令模式,这个模式从名字上看就很简单,命令嘛,老大发命令,小兵执行就是了,确实是这个意思,
但是更深化了,用模式来描述真是是世界的命令情况。正在看这本书的你,我猜测分为两类:已经工作的和没有
工作的,先说没有工作的,那你为啥要看这本书,为了以后工作呗,只要你参见工作,你肯定会待在项目组,那
今天我们就以项目组为例子来讲述命令模式。
我是我们部门的项目经理,就是一个项目的头,在中国做项目,项目经理就是什么都要懂,什么都要管,做
好了项目经理能分到一杯羹,做不好都是你项目经理的责任,这个是绝对的,我带过太多的项目,行政命令一压
下来,那就一条道,做完做好!我们虽然是一个集团公司,但是我们部门是独立核算的,就是说呀,我们部门不
仅仅为我们集团服务,还可以为其他甲方服务,赚取更多的外快,所以俺们的工资才能是中上等。在 2007 年我
带领了一个项目,比较小,但是钱可不少,是做什么的呢?为一家旅行社建立一套内部管理系统,管理他的客户、
旅游资源、票务以及内部管理,整体上类似一个小型的 ERP 系统,门店比较多,员工也比较多,但是需求比较
明确,因为他们之前有一套自己购买的内部管理系统,这次变动部分模块基本上是翻版,而且旅行社有自己的
IT 部门,比较好相处,都是技术人员,没有交流鸿沟嘛。
这个项目的成员分工也是采用了常规的分工方式,分为需求组(Requirement Group,简称 RG)、美工
组(Page Group,简称 PG)、代码组(我们内部还有一个比较优雅的名字:逻辑实现组,这里使用大家经常称
呼的名称吧,英文缩写叫 Code Group,简称 CG),总共加上我这个项目经理正好十个人,刚开始的时候客户
(也就是旅行社,甲方)还是很乐意和我们每个组探讨,比如和需求组讨论需求,和美工讨论页面,和代码组讨
论实现,告诉他们修改这里,删除这里,增加这些等等,这是一种比较常见的甲乙方合作模式,甲方深入到乙方
的项目开发中,我们把这个模式用类图表示一下:
这个类图很简单,客户和三个组都有交流,这也合情合理,那我们看看这个的实现,首先看抽象类,我们是
面向接口或抽象类编程的嘛:
也就是命令模式中的命令接收者角色(Receiver),等会细讲。我们再看三个实现类,需求组最重要,没有需求
你还设计个 P 呀,看 RequirmentGroup 类的实现:
要,看 PageGroup 的实现:
代码组,与上类同,这里不写了。
整个项目的三个支柱都已经产生了,那看客户怎么和我们谈。客户刚刚开始给了我们一份他们自己写的一份
需求,还是比较完整的,需求组根据这份需求写了一份分析说明书,客户一看,不对,要增加点需求,看程序:
-------------客户要求增加一个需求-----------------
找到需求组...
客户要求增加一项需求...
客户要求需求变更计划...
好的,客户的需求达到了,需求刚开始没考虑周全,增加需求是在所难免的嘛,理解理解。然后又过了段时
间,客户说“界面多画了一个,过来谈谈”,于是:
-------------客户要求增加一个页面-----------------
找到美工组...
客户要求删除一个页面...
客户要求页面变更计划...
好了,界面也谈过了,应该没什么大问题了吧。过了一天后,客户又让代码组过去,说是数据库设计问题,
然后又叫美工过去,布置了一堆命令,这个我就不一一写了,大家应该能够体会到,你做过项目的话,这种体会
更深,客户让修改你不修改?项目不想做了你!
但是问题来了,我们修改可以,但是每次都是叫一个组去,布置个任务,然后出计划,次次都这样,如果让
你当甲方也就是客户,你烦不烦?而且这种方式很容易出错误呀,而且还真发生过,客户把美工叫过去了,要删
除,可美工说需求是这么写的,然后客户又命令需求组过去,一次次的折腾,客户也烦躁了,于是直接抓住我这
个项目经理说:
“我不管你们内部怎么安排,你就给我找个接头人,我告诉他怎么做,删除页面了,增加功能了,你们内部怎么处理,我就告诉他我要干什么就成了…”
我一听,好呀,这也正是我想要的,我项目组的兄弟们也已经受不了了,于是我改变了一下我的处理方式,
看看类图:
类图中增加了不少,看着也比较清晰,比较简单的(Command 抽象类与 Group 抽象类是没有关联关系的,
与 Group 的三个实现类是有关联关系,为了线条不交叉就直接画上父类有关系),增加的几个类说明如下:
Command 抽象类:客户发给我们的命令,定义三个工作组的成员变量,供子类使用;定义一个抽象方法
execute,由子类来实现;
Invoker 实现类:项目接头人,setComand 接受客户发给我我们的命令,action 方法是执行客户的命令
(方法名写成是 action 是与 command 的 execute 区分开,避免混淆)
我们先看 Command 抽象类代码:
(DeleteRequirementCommand)等等,这里就不用描述了,都很简单。
我们再看我们的接头人,就是 Invoker 类的实现:
这个是更简单了,简单是简单,可以帮我们解决很多问题,我们再看一下客户提出变更的过程:
-------------客户要求增加一项需求-----------------
找到需求组...
客户要求增加一项需求...
客户要求需求变更计划...
那我们看看,如果客户要求删除一个页面,那我们的修改有多大呢?想想,Look:
运行结果如下:
-------------客户要求删除一个页面-----------------
找到美工组...
客户要求删除一项需求...
客户要求需求变更计划...
看到上面打黄色的代码来吗?就修改了这么多,就完成了一个命令的,是不是很简单,而且客户也不用知道
到底要谁来修改,这个他不需要知道的,高内聚的要求体现出来了,这就是命令模式。
博客地址 http://blog.csdn.net/ftx2540993425
下面横线以上内容是借鉴别人的,为了表达对作者的敬意,不做不恰当的修改,我个人的总结在后面。好的东西
今天讲命令模式,这个模式从名字上看就很简单,命令嘛,老大发命令,小兵执行就是了,确实是这个意思,
但是更深化了,用模式来描述真是是世界的命令情况。正在看这本书的你,我猜测分为两类:已经工作的和没有
工作的,先说没有工作的,那你为啥要看这本书,为了以后工作呗,只要你参见工作,你肯定会待在项目组,那
今天我们就以项目组为例子来讲述命令模式。
我是我们部门的项目经理,就是一个项目的头,在中国做项目,项目经理就是什么都要懂,什么都要管,做
好了项目经理能分到一杯羹,做不好都是你项目经理的责任,这个是绝对的,我带过太多的项目,行政命令一压
下来,那就一条道,做完做好!我们虽然是一个集团公司,但是我们部门是独立核算的,就是说呀,我们部门不
仅仅为我们集团服务,还可以为其他甲方服务,赚取更多的外快,所以俺们的工资才能是中上等。在 2007 年我
带领了一个项目,比较小,但是钱可不少,是做什么的呢?为一家旅行社建立一套内部管理系统,管理他的客户、
旅游资源、票务以及内部管理,整体上类似一个小型的 ERP 系统,门店比较多,员工也比较多,但是需求比较
明确,因为他们之前有一套自己购买的内部管理系统,这次变动部分模块基本上是翻版,而且旅行社有自己的
IT 部门,比较好相处,都是技术人员,没有交流鸿沟嘛。
这个项目的成员分工也是采用了常规的分工方式,分为需求组(Requirement Group,简称 RG)、美工
组(Page Group,简称 PG)、代码组(我们内部还有一个比较优雅的名字:逻辑实现组,这里使用大家经常称
呼的名称吧,英文缩写叫 Code Group,简称 CG),总共加上我这个项目经理正好十个人,刚开始的时候客户
(也就是旅行社,甲方)还是很乐意和我们每个组探讨,比如和需求组讨论需求,和美工讨论页面,和代码组讨
论实现,告诉他们修改这里,删除这里,增加这些等等,这是一种比较常见的甲乙方合作模式,甲方深入到乙方
的项目开发中,我们把这个模式用类图表示一下:
这个类图很简单,客户和三个组都有交流,这也合情合理,那我们看看这个的实现,首先看抽象类,我们是
面向接口或抽象类编程的嘛:
package com.cbf4life; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 项目组分成了三个组,每个组还是要接受增删改的命令 */ public abstract class Group { //甲乙双方分开办公,你要和那个组讨论,你首先要找到这个组 public abstract void find(); //被要求增加功能 public abstract void add(); //被要求删除功能 public abstract void delete(); //被要求修改功能 public abstract void change(); //被要求给出所有的变更计划 public abstract void plan(); }大家看抽象类中的每个方法,是不是每个都是一个命令?找到它,增加,删除,给我计划!是不是命令,这
也就是命令模式中的命令接收者角色(Receiver),等会细讲。我们再看三个实现类,需求组最重要,没有需求
你还设计个 P 呀,看 RequirmentGroup 类的实现:
package com.cbf4life; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 需求组的职责是和客户谈定需求,这个组的人应该都是业务领域专家 */ 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("客户要求需求变更计划..."); } }需求组有了,我们再看美工组,美工组也很重要,是项目的脸面,客户最终接触到的还是界面,这个非常重
要,看 PageGroup 的实现:
package com.cbf4life; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 美工组的职责是设计出一套漂亮、简单、便捷的界面 */ 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("客户要求页面变更计划..."); } }
代码组,与上类同,这里不写了。
整个项目的三个支柱都已经产生了,那看客户怎么和我们谈。客户刚刚开始给了我们一份他们自己写的一份
需求,还是比较完整的,需求组根据这份需求写了一份分析说明书,客户一看,不对,要增加点需求,看程序:
package com.cbf4life; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 客户就是甲方,给我们钱的一方,是老大 */ public class Client { public static void main(String[] args) { //首先客户找到需求组说,过来谈需求,并修改 System.out.println("-------------客户要求增加一个需求-----------------"); Group rg = new RequirementGroup(); //找到需求组 rg.find(); //增加一个需求 rg.add(); //要求变更计划 rg.plan(); } }运行的结果如下:
-------------客户要求增加一个需求-----------------
找到需求组...
客户要求增加一项需求...
客户要求需求变更计划...
好的,客户的需求达到了,需求刚开始没考虑周全,增加需求是在所难免的嘛,理解理解。然后又过了段时
间,客户说“界面多画了一个,过来谈谈”,于是:
package com.cbf4life; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 客户就是甲方,给我们钱的一方,是老大 */ public class Client { public static void main(String[] args) { //首先客户找到美工组说,过来谈页面,并修改 System.out.println("-------------客户要求删除一个页面-----------------"); Group pg = new PageGroup(); //找到需求组 pg.find(); //增加一个需求 pg.delete(); //要求变更计划 pg.plan(); } }运行结果如下:
-------------客户要求增加一个页面-----------------
找到美工组...
客户要求删除一个页面...
客户要求页面变更计划...
好了,界面也谈过了,应该没什么大问题了吧。过了一天后,客户又让代码组过去,说是数据库设计问题,
然后又叫美工过去,布置了一堆命令,这个我就不一一写了,大家应该能够体会到,你做过项目的话,这种体会
更深,客户让修改你不修改?项目不想做了你!
但是问题来了,我们修改可以,但是每次都是叫一个组去,布置个任务,然后出计划,次次都这样,如果让
你当甲方也就是客户,你烦不烦?而且这种方式很容易出错误呀,而且还真发生过,客户把美工叫过去了,要删
除,可美工说需求是这么写的,然后客户又命令需求组过去,一次次的折腾,客户也烦躁了,于是直接抓住我这
个项目经理说:
“我不管你们内部怎么安排,你就给我找个接头人,我告诉他怎么做,删除页面了,增加功能了,你们内部怎么处理,我就告诉他我要干什么就成了…”
我一听,好呀,这也正是我想要的,我项目组的兄弟们也已经受不了了,于是我改变了一下我的处理方式,
看看类图:
类图中增加了不少,看着也比较清晰,比较简单的(Command 抽象类与 Group 抽象类是没有关联关系的,
与 Group 的三个实现类是有关联关系,为了线条不交叉就直接画上父类有关系),增加的几个类说明如下:
Command 抽象类:客户发给我们的命令,定义三个工作组的成员变量,供子类使用;定义一个抽象方法
execute,由子类来实现;
Invoker 实现类:项目接头人,setComand 接受客户发给我我们的命令,action 方法是执行客户的命令
(方法名写成是 action 是与 command 的 execute 区分开,避免混淆)
我们先看 Command 抽象类代码:
package com.cbf4life.command; import com.cbf4life.receiver.CodeGroup; import com.cbf4life.receiver.PageGroup; import com.cbf4life.receiver.RequirementGroup; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 命令的抽象类,我们把客户发出的命令定义成一个一个的对象 */ public abstract class Command { //把三个组都定义好,子类可以直接使用 protected RequirementGroup rg = new RequirementGroup(); //需求组 protected PageGroup pg = new PageGroup(); //美工组 protected CodeGroup cg = new CodeGroup(); //代码组; //只要一个方法,你要我做什么事情 public abstract void execute(); }这个简单, 看两个具体的实现类, 先看 AddRequeirementCommand 类, 这个类的作用就是增加一项需求。
package com.cbf4life.command; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 增加一项需求 */ public class AddRequirementCommand extends Command { //执行增加一项需求的命令 public void execute() { //找到需求组 super.rg.find(); //增加一份需求 super.rg.add(); //给出计划 super.rg.plan(); } }看删除一个页面的命令,DeletePageCommand 类:
package com.cbf4life.command; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 删除一个页面的命令 */ public class DeletePageCommand extends Command { //执行删除一个页面的命令 public void execute() { //找到页面组 super.pg.find(); //删除一个页面 super.rg.delete(); //给出计划 super.rg.plan(); } }Command 抽象类还可以有很多的子类,比如增加一个功能命令(AddCodeCommand),删除一份需求命令
(DeleteRequirementCommand)等等,这里就不用描述了,都很简单。
我们再看我们的接头人,就是 Invoker 类的实现:
package com.cbf4life.invoker; import com.cbf4life.command.Command; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 接头人的职责就是接收命令,并执行 */ public class Invoker { //什么命令 private Command command; //客户发出命令 public void setCommand(Command command){ this.command = command; } //执行客户的命令 public void action(){ this.command.execute(); } }
这个是更简单了,简单是简单,可以帮我们解决很多问题,我们再看一下客户提出变更的过程:
package com.cbf4life; import com.cbf4life.command.AddRequirementCommand; import com.cbf4life.command.Command; import com.cbf4life.invoker.Invoker; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 客户就是甲方,给我们钱的一方,是老大 */ public class Client { public static void main(String[] args) { //定义我们的接头人 Invoker xiaoSan = new Invoker(); //接头人就是我小三 //客户要求增加一项需求 System.out.println("-------------客户要求增加一项需求-----------------"); //客户给我们下命令来 Command command = new AddRequirementCommand(); //接头人接收到命令 xiaoSan.setCommand(command); //接头人执行命令 xiaoSan.action(); } }运行结果如下:
-------------客户要求增加一项需求-----------------
找到需求组...
客户要求增加一项需求...
客户要求需求变更计划...
那我们看看,如果客户要求删除一个页面,那我们的修改有多大呢?想想,Look:
package com.cbf4life; import com.cbf4life.command.Command; import com.cbf4life.command.DeletePageCommand; import com.cbf4life.invoker.Invoker; /** * @author cbf4Life cbf4life@126.com * I'm glad to share my knowledge with you all. * 客户就是甲方,给我们钱的一方,是老大 */ public class Client { public static void main(String[] args) { //定义我们的接头人 Invoker xiaoSan = new Invoker(); //接头人就是我小三 //客户要求增加一项需求 System.out.println("-------------客户要求删除一个页面-----------------"); //客户给我们下命令来 //Command command = new AddRequirementCommand(); Command command = new DeletePageCommand(); //接头人接收到命令 xiaoSan.setCommand(command); //接头人执行命令 xiaoSan.action(); } }
运行结果如下:
-------------客户要求删除一个页面-----------------
找到美工组...
客户要求删除一项需求...
客户要求需求变更计划...
看到上面打黄色的代码来吗?就修改了这么多,就完成了一个命令的,是不是很简单,而且客户也不用知道
到底要谁来修改,这个他不需要知道的,高内聚的要求体现出来了,这就是命令模式。
相关文章推荐
- (实训第一天)Linux系统常用命令以及基本概念
- 这货把360安全路由P1、极路由3、全新小米路由器都干翻了
- 七牛对用户使用webp图片格式的使用建议
- .NET学习(十二)页面跳转
- 标签TextView
- Caffe傻瓜系列(7):solver优化方法
- hdoj2412Party at Hali-Bula【树形dp】
- 文章标题
- java+ajax实现数据分批加载到前端
- IOS中把字符串加密/IOS中怎么样MD5加密/IOS中NSString分类的实现
- 字符串数组与字符串指针
- 迪米特法则
- jslearning1
- eclipse发布项目报错:Multiple Contexts hava a path of “/xxx“
- RequestMapping 方法里适配返回值为string 或者json对象
- Unity3D手游开发日记(4) - 适合移动平台的热浪扭曲
- Clustering as a Mixture of Gaussians
- Python Base of Scientific Stack(Python基础之科学栈)
- Python Base of Scientific Stack(Python基础之科学栈)
- Linux kill, killall, kill -9