命令模式的定义
命令模式是一个高内聚的模式,其定义为:Encapsulate a request as an object,therebyletting you parameterize clients with different requests,queue or log requests,and support undoableoperations.(将一个请求封装成一个对象,从而让你使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能。)
命令模式的通用类图在该类图中,我们看到三个角色:
- Receive接收者角色
该角色就是干活的角色,命令传递到这里是应该被执行的,具体到我们上面的例子中就是Group的三个实现类。 - Command命令角色
需要执行的所有命令都在这里声明。 - Invoker调用者角色
接收到命令,并执行命令。在例子中,我(项目经理)就是这个角色。命令模式比较简单,但是在项目中非常频繁地使用,因为它的封装性非常好,把请求方(Invoker)和执行方(Receiver)分开了,扩展性也有很好的保障,通用代码比较简单
演示代码
这次是项目经理的一个工作模拟。模拟一个项目的开发过程。
项目的成员分工采用了常规的分工方式,分为需求组(Requirement Group,RG)、美工组(Page Group,PG)、代码组(我们内部还有一个比较优雅的名字:逻辑实现组,这里使用大家经常称呼的名称,即Code Group,简称CG),加上我这个项目经理正好十个人。刚开始,客户(也就是旅行社,甲方)很乐意和我们每个组探讨,比如和需求组讨论需求、和美工讨论页面、和代码组讨论实现,告诉他们修改、删除、增加各种内容等。这是一种比较常见的甲乙方合作模式,甲方深入到乙方的项目开发中,我们可以使用类图来表示这个过程,
image.png项目的初期都是一步一步摸索的,双方的合作也一样。啥也不说了可是工作!!。
1.抽象类Group
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(){
//根据日志进行回滚
}
}
大家看抽象类中的每个方法,其中的每个都是一个命令语气——“找到它,增加,删除,给我计划!”这些都是命令,给出命令然后由相关的人员去执行。
2.接着实现3个小组
需求组
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 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 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("客户要求代码变更计划...");
}
}
整个项目的3个支柱都已经产生了,那看客户怎么和我们谈。客户刚开始提交了他们自己写的一份比较完整的需求,需求组根据这份需求写了一份分析说明书,客户看后,要求增加需求,
3.甲方爸爸要发话了
public class Client {
public static void main(String[] args) {
//首先客户找到需求组说,过来谈需求,并修改
System.out.println("-------------客户要求增加一个需求-----------------");
Group rg = new RequirementGroup();
//找到需求组
rg.find();
//增加一个需求
rg.add();
//要求变更计划
rg.plan();
}
}
-------------客户要求增加一个需求-----------------
找到需求组...
客户要求增加一项需求...
客户要求需求变更计划...
好了,界面也谈过了,应该没什么大问题了吧。过了一天后,客户又让代码组过去,说是数据库设计问题,然后又叫美工组过去,布置了一堆命令……这个就不一一写了,大家应该能够体会得到!问题来了,我们修改可以,但是每次都是叫一个组去,布置个任务,然后出计划,每次都这样,如果让你当甲方,你烦不烦?而且这种方式很容易出错误,并且还真发生过。客户把美工叫过去了,要删除,可美工说需求是这么写的,然后客户又命令需求组过去,一次次地折腾之后,客户也烦躁了,于是直接抓住我这个项目经理说:“我不管你们内部怎么安排,你就给我找个接头负责人,我告诉他怎么做,删除页面,增加功能,你们内部怎么处理我不管,我就告诉他我要干什么就成了……”
我一听,好啊,这也正是我想要的,我们项目组的兄弟们也已经受不了了,于是我改变了一下我的处理方式,
在原有的类图上增加了一个Invoker类,其作用是根据客户的命令安排不同的组员进行工作,例如,客户说“界面上删除一条记录”,Invoker类接收到该String类型命令后,通知美工组PageGroup开始delete,然后再找到代码组CodeGroup后台不要存到数据库中,最后反馈给客户一个执行计划。这是一个挺好的方案,但是客户的命令是一个String类型的,这有非常
多的变化,仅仅通过一个字符串来传递命令并不是一个非常好的方案,因为在系统设计中,字符串没有约束力,根据字符串判断相关的业务逻辑不是一个优秀的解决方案。那怎么才是一个优秀的方案呢?解决方案是:对客户发出的命令进行封装,每个命令是一个对象,避免客户、负责人、组员之间的交流误差,封装后的结果就是客户只要说一个命令,我的项目组就立刻开始启动。不用思考、解析命令字符串,
Command抽象类只有一个方法execute,其作用就是执行命令,子类非常坚决地实现该命令,与军队中类似,上级军官给士兵发布命令:爬上这个旗杆!然后士兵回答:Yes,Sir!完美的项目也与此类似,客户发送一个删除页面的命令,接头负责人Invoker接收到命令后,立刻执行DeletePageCommand的execute方法。对类图中增加的几个类说明如下。
- Command抽象类:客户发给我们的命令,定义三个工作组的成员变量,供子类使用;定义一个抽象方法execute,由子类来实现。
- CInvoker实现类:项目接头负责人,setComand接收客户发给我们的命令,action方法是执行客户的命令(方法名写成是action,与command的execute区分开,避免混淆)。
继续我们的加班之旅吧!!
1.抽象命令类
public abstract class Command {
//把三个组都定义好,子类可以直接使用
protected RequirementGroup rg = new RequirementGroup(); //需求组
protected PageGroup pg = new PageGroup(); //美工组
protected CodeGroup cg = new CodeGroup(); //代码组;
//只要一个方法,你要我做什么事情
public abstract void execute();
}
抽象类很简单,具体的实现类只要实现execute方法就可以了。
2.增加需求的命令
public class AddRequirementCommand extends Command {
// 执行增加一项需求的命令
public void execute() {
// 找到需求组
super.rg.find();
// 增加一份需求
super.rg.add();
// 页面也要增加
super.pg.add();
// 功能也要增加
super.cg.add();
// 给出计划
super.rg.plan();
}
}
3.删除页面的命令
public class DeletePageCommand extends Command {
//执行删除一个页面的命令
public void execute() {
//找到页面组
super.pg.find();
//删除一个页面
super.rg.delete();
//给出计划
super.rg.plan();
}
}
Command抽象类可以有N个子类,如增加一个功能命令(AddFunCommand),删除一份需求命令(DeleteRequirementCommand)等,这里就不再描述了,只要是由客户产生、时常性的行为都可以定义为一个命令,其实现类都比较简单。
4.负责人
public class Invoker {
// 什么命令
private Command command;
// 客户发出命令
public void setCommand(Command command) {
this.command = command;
}
// 执行客户的命令
public void action() {
this.command.execute();
}
}
这更简单了,负责人只要接到客户的命令,就立刻执行。
5.甲方爸爸又开始提需求了
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();
}
}
-------------客户要求删除一个页面-----------------
找到美工组...
客户要求删除一项需求...
客户要求需求变更计划...
嗯!这次都不累了。和甲方的合作还算愉快。
命令模式的优点
- 类间解耦
调用者角色与接收者角色之间没有任何依赖关系,调用者实现功能时只需调用Command抽象类的execute方法就可以,不需要了解到底是哪个接收者执行。 - 可扩展性
Command的子类可以非常容易地扩展,而调用者Invoker和高层次的模块Client不产生严重的代码耦合。 - 命令模式结合其他模式会更优秀
命令模式可以结合责任链模式,实现命令族解析任务;结合模板方法模式,则可以减少Command子类的膨胀问题。
命令模式的缺点
命令模式也是有缺点的,请看Command的子类:如果有N个命令,问题就出来了,Command的子类就可不是几个,而是N个,这个类膨胀得非常大,这个就需要读者在项目中慎重考虑使用。
命令模式的使用场景
只要你认为是命令的地方就可以采用命令模式,例如,在GUI开发中,一个按钮的点击是一个命令,可以采用命令模式;模拟DOS命令的时候,当然也要采用命令模式;触发-反馈机制的处理等。
网友评论