今天讲命令模式，这个模式从名字上看就很简单，命令嘛，老大发命令，小兵执行就是了，确实是这个意思，但是更深化了，用模式来描述真是世界的命令情况。正在看这本书的你，我猜测分为两类：已经工作的和没有工作的，先说没有工作的，那你为啥要看这本书，为了以后工作呗，只要你参加工作，你肯定会待在项目组，那今天我们就以项目组为例子来讲述命令模式。
我是我们部门的项目经理，就是一个项目的头，在中国做项目，项目经理就是什么都要懂，什么都要管，做好了项目经理能分到一杯羹，做不好都是你项目经理的责任，这个是绝对的，我带过太多的项目，行政命令一压下来，那就是一条道，做完做好！在2007年我带领了一个项目，比较小，但是钱可不少，是做什么的呢？为一家旅行社建立一套内部管理系统，管理它的客户、旅游资源，因为他们之前有一套自己购买的内部管理系统，这次变动部分模块基本上是翻版，而且旅行社有自己的IT部门，比较好相处，都是技术人员，没有交流鸿沟吗。
这个项目的员工也是采用了常规的分工方式，分为需求组（Requirement Group，简称 RG）、美工组（Page Group，简称PG）、代码组（Code Group，简称CG）,总共加上我这个项目经理正好是个人，刚开始的时候客户（也就是旅行社，甲方）还是很乐意和我们组探讨，比如和需求组讨论需求，和美工讨论页面，和代码组讨论实现，告诉他们修改这里，删除这里，增加这些等等，这是一种比较常见的甲乙方合作模式，甲方深入到乙方的项目开发中，下面我们用代码来实现。
目录：
抽象类：Group.java 每个组都要接受增删改的命令
package No12_CommandPattern;
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），等回细讲。我们再看三个实现类，需求组最重要，没有需求设计什么，来看RequirementGroup类的实现：
RequirementGroup.java
package No12_CommandPattern;
/**
* 需求组的职责是和客户谈定需求，这个组的人应该都是业务领域专家
*/
public class RequirementGroup extends Group {
//客户要求需求组过去和他们谈谈
@Override
public void find() {
System.out.println("找到需求组...");
}
//客户要求增加一项需求
@Override
public void add() {
System.out.println("客户要求增加一项需求...");
}
//客户要求删除一项需求
@Override
public void delete() {
System.out.println("客户要求删除一项需求");
}
//客户要求修改一项需求
@Override
public void change() {
System.out.println("客户要求修改一项需求...");
}
//客户要求出变更计划
@Override
public void plan() {
System.out.println("客户要求需求变更计划...");
}
}
需求组有了，我们再看美工组，美工组也很重要，是项目的脸面，客户最终接触到的还是界面，这个非常重要
PageGroup.java
package No12_CommandPattern;
/**
* 美工组的职责是设计出一套漂亮、简单、便捷的界面
*/
public class PageGroup extends Group {
//首先这个美工组应该被找到把，要不你跟谁谈？
@Override
public void find() {
System.out.println("找到美工组...");
}
//美工组被要求增加一个页面
@Override
public void add() {
System.out.println("客户要求增加一个页面...");
}
//甲方是老大，要求删除一些页面
@Override
public void delete() {
System.out.println("客户要求删除一个页面...");
}
//客户要求对先有界面做修改
@Override
public void change() {
System.out.println("客户要求修改一个页面...");
}
//所有的增删改那要给出计划呀
@Override
public void plan() {
System.out.println("客户要求页面变更计划...");
}
}
最后看代码组，这个组的成员一般都是比较闷骚型的，不多说话，但多做事，比较沉闷，这是这个组的典型特点，我们来看看这个CodeGroup类：
CodeGroup.java
package No12_CommandPattern;
/**
* 代码组的职责是实现业务逻辑，当然包括数据库设计了
*/
public class CodeGroup extends Group {
//客户要求代码组过去和他们谈
@Override
public void find() {
System.out.println("找到代码组...");
}
//客户要求增加一项功能
@Override
public void add() {
System.out.println("客户要求增加一项功能...");
}
//客户要求删除一项功能
@Override
public void delete() {
System.out.println("客户要求删除一项功能");
}
//客户要求修改一项内容
@Override
public void change() {
System.out.println("客户要求修改一项内容");
}
//客户要求出变更计划
@Override
public void plan() {
System.out.println("客户要求出变更计划i");
}
}
整个项目的三个支柱都已经产生了，那看客户怎么和我们谈。客户刚刚开始给了我们一份他们自己写的一份需求，还是比较完整的，需求组根据这份需求写了一份分析说明书，客户一看，不对，要增加点需求，看程序：
package No12_CommandPattern;
public class Client {
public static void main(String[] args) {
//首先客户找到需求组说，过来谈需求，并修改
System.out.println("-----客户要求增加一个需求------");
Group rg = new RequirementGroup();
//找到需求组
rg.find();
//增加一个需求
rg.add();
//需求变更计划
rg.plan();
}
}
运行结果：
好的，客户的需求达到了，需求刚开始没考虑周全，增加需求是在所难免的嘛，理解理解。然后又过了段时间，客户说“界面多画了一个，过来谈谈”，于是：
package No12_CommandPattern;
public class Client {
public static void main(String[] args) {
//首先客户找到美工组说，过来谈页面，并修改
System.out.println("------客户要求删除一个页面------");
Group pg = new PageGroup();
//找到需求组
pg.find();
//增加一个需求
pg.delete();
//要求变更计划
pg.plan();
}
}
运行结果：
好了，界面也谈过了，应该没什么大问题了吧。过了一天后，客户又让代码组过去，说是数据库设计问题，然后又叫美工过去，布置了一堆命令，这个我就不一一写了，大家应该能够体会到，你做过项目的话，这种体会更深，客户让修改你不修改？项目不想做了你！
但是问题来了，我们修改可以，但是每次都是叫一个组去，布置个任务，然后出计划，次次都是这样，如果让你当甲方也就是客户，你烦不烦？而且这种方式很容易出错呀，而且还真发生过，客户把美工叫过去了，要删除，可美工说需求是这么写的，然后客户又命令需求组过去，一次次的折腾，客户也烦躁了，于是直接抓住我这个项目经理说：
“我不管你们内部怎么安排，你就给我找个接头人，我告诉他怎么做，删除页面了，增加功能了，你们内部怎么处理，我就告诉他我要干什么就成了.....”
我一听，好呀，这也正是我想要的，我项目组的兄弟们也已经受不了了，于是我改变了一下我的处理方式
增加的几个类说明如下：
Command 抽象类：客户发给我们的命令，定义三个工作组的成员变量，供子类使用；定义一个抽象的方法execute，由子类来实现；
Invoker 实现类：项目接头人，setComand接受客户发给我们的命令，action 方法是执行客户的命令（方法名写成是action是与 command 的 execute 区分开，避免混淆）
现在的目录是这样：
Command.java
package No12_CommandPattern;
public abstract class Command {
//把三个组都定义好了，子类可以直接使用
protected RequirementGroup rg = new RequirementGroup();//需求组
protected PageGroup pg = new PageGroup(); //美工组
protected CodeGroup cg = new CodeGroup(); //代码组
//只要一个方法，你要我做什么事情
public abstract void execute();
}
再来看AddRequirementCommand 类，这个类的作用就是增加一项需求。
package No12_CommandPattern;
public class AddRequirementCommand extends Command {
@Override
public void execute() {
//找到需求组
super.rg.find();
//增加一份需求
super.rg.add();
//给出计划
super.rg.plan();
}
}
看删除一个页面的命令，DeletePageCommand 类
package No12_CommandPattern;
public class DeletePageCommand extends Command {
@Override
public void execute() {
super.pg.find();
super.pg.find();
super.pg.plan();
}
}
Command抽象类还可以有很多的子类，比如增加一个功能命令（AddCodeCommand），删除一份需求命令（DeleteRequirementCommand）等等，这里就不用描述了，都很简单。
我们再看看我们的接头人，就是Invoker类的实现：
package No12_CommandPattern;
public class Invoker {
private Command command;
public void setCommand(Command command) {
this.command = command;
}
public void action(){
this.command.execute();
}
}
看一下客户提出的变更的过程：
package No12_CommandPattern;
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 No12_CommandPattern;
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();
}
}
运行结果：
看到了吧，就修改了一行，就完成了一个命令，是不是很简单，而且客户也不用知道到底要谁来修改，这个他不需要知道的，高内聚的要求体现出来了，这就是命令模式。
我们来看看程序中的角色：
Receiver 角色：这个就是干活的角色，命令传递到这里是应该被执行的，具体到上面我们的例子中就是Group的三个实现类。
Command角色：就是命令，需要我执行的所有命令都在这里声明；
Invoker角色：调用者，接受到命令，并执行命令，例子中我这里项目经理就是这个角色；
命令模式比较简单，但是在项目中使用时非常频繁的，封装性非常好，因为它把请求方（Invoker）和执行方（Receiver）分开了，扩展性也有很好的保障。但是，命令模式也是有缺点的，你看Command的子类没有，那个如果我要是写下去的可不是几个，而是十几个，这个类膨胀的非常多，这个就需要大家在项目中自己考虑使用了。
上面的例子我还没有说完，我们想想，客户要求增加一项需求，那是不是页面也增加，同时功能也要增加呢？如果不使用命令模式，客户就需要先找需求组，然后找美工组，然后找代码组，这个...，你想让客户跳楼呀...，使用命令模式后，客户只管发命令模式，你增加一项需求，没问题，我内部调动三个组通力合作，然后反馈你结果，这也正是客户需要的，那这个要怎么修改呢？想想看，很简单的，在AddRequirementCommand 类的execute方法中增加对PageGroup 和 CodePage的调用就成了，修改后的代码如下：
AddRequirementCommand.java
package No12_CommandPattern;
public class AddRequirementCommand extends Command {
@Override
public void execute() {
//找到需求组
super.rg.find();
//增加一份需求
super.rg.add();
//页面也要增加
super.pg.add();
//功能也要增加
super.cg.add();
//给出计划
super.rg.plan();
}
}
看看，是不是就解决问题了？命令模式做了一层非常好的封装。
内容来自《24种设计模式介绍与6大设计原则》和一些个人理解