接下来讲命令模式，这个模式从名字上看就很简单，命令嘛，老大发命令，小兵执行就是了，确实是这个意思，但是更深化了，用模式来描述真是是世界的命令情况。我们就以项目组为例子来讲述命令模式。
项目的成员分工也是采用了常规的分工方式，分为需求组（Requirement Group，简称RG）、美工组（Page Group,简称PG）、代码组（我们内部还有一个比较优雅的名字：逻辑实现组，这里使用大家经常称呼的名称吧，英文缩写叫Code Group，简称CG），加上项目经理，刚开始的时候客户（也就是旅行社，甲方）还是很乐意和我们每个组探讨，比如和需求组讨论需求，和美工讨论页面，和代码组讨论实现，告诉他们修改这里，删除这里，增加这些等等，这是一种比较常见的甲乙方合作模式，甲方深入到乙方的项目开发中。
用户对界面不满意，就去找美工组谈；界面也谈过了，应该没什么大问题了吧。过了一天后，客户又让代码组过去，说是数据库设计问题，然后又叫美工过去，布置了一堆命令，这个我就不一一写了，大家应该能够体会到，你做过项目的话，这种体会更深，客户让修改你不修改？项目不想做了你!
但是问题来了，我们修改可以，但是每次都是叫一个组去，布置个任务，然后出计划，次次都这样，如果让你当甲方也就是客户，你烦不烦？而且这种方式很容易出错误呀，而且还真发生过，客户把美工叫过去了，要删除，可美工说需求是这么写的，然后客户又命令需求组过去，一次次的折腾，客户也烦躁了，于是直接抓住项目经理说：“我不管你们内部怎么安排，你就给我找个接头人，我告诉他怎么做，删除页面了，增加功能了，你们内部怎么处理，我就告诉他我要干什么就成了…”。于是就用到了命令模式。
命令模式（Command）：将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。来看下类图：
类图中增加了不少，看着也比较清晰，比较简单的（Command抽象类与Group抽象类是没有关联关系的，与Group的三个实现类是有关联关系，为了线条不交叉就直接画上父类有关系），增加的几个类说明如下：
Command抽象类：客户发给我们的命令，定义三个工作组的成员变量，供子类使用；定义一个抽象方法execute，由子类来实现；
Invoker实现类:项目接头人，setComand接受客户发给我们的命令，action方法是执行客户的命令（方法名写成是action是与command的execute区分开，避免混淆）
Receiver类：即Group
分析一下原理：以客户需要增加需求命令为例。客户端约见接头人Invoker，发出一个增加需求命令“Command command = new AddRequirementCommand();”，接头人接下命令"invoker.setCommand(AddRequirementCommand)",完了回公司之后接头人就要将客户的要求传达给需求组，于是在invoker就执行他的action方法，其方法内容无非就是客户传入的command.excute(),最后的劳动力还是底层的RequirementGroup（即命令模式里的另一个重要的类Receiver）执行（苦逼的程序员）！
一句话概括命令模式：适配器和策略的结合，把请求和对象分开！