您的设计模式——命令模式【Command Pattern 】

忘是亡心i 2022-10-01 00:57 171阅读 0赞

今天讲命令模式，这个模式从名字上看就很简单，命令嘛，老大发命令，小兵执行就是了，确实是这个意思，  
但是更深化了，用模式来描述真是是世界的命令情况。正在看这本书的你，我猜测分为两类：已经工作的和没有  
工作的，先说没有工作的，那你为啥要看这本书，为了以后工作呗，只要你参加工作，你肯定会待在项目组，那  
今天我们就以项目组为例子来讲述命令模式。  
我是我们部门的项目经理，就是一个项目的头，在中国做项目，项目经理就是什么都要懂，什么都要管，做  
好了项目经理能分到一杯羹，做不好都是你项目经理的责任，这个是绝对的，我带过太多的项目，行政命令一压  
下来，那就一条道，做完做好！我们虽然是一个集团公司，但是我们部门是独立核算的，就是说呀，我们部门不  
仅仅为我们集团服务，还可以为其他甲方服务，赚取更多的外快，所以俺们的工资才能是中上等。在 2007 年我  
带领了一个项目，比较小，但是钱可不少，是做什么的呢？为一家旅行社建立一套内部管理系统，管理他的客户、  
旅游资源、票务以及内部管理，整体上类似一个小型的 ERP 系统，门店比较多，员工也比较多，但是需求比较  
明确，因为他们之前有一套自己购买的内部管理系统，这次变动部分模块基本上是翻版，而且旅行社有自己的  
IT 部门，比较好相处，都是技术人员，没有交流鸿沟嘛。  
这个项目的成员分工也是采用了常规的分工方式，分为需求组（Requirement Group，简称 RG）、美工  
组（Page Group,简称 PG）、代码组（我们内部还有一个比较优雅的名字：逻辑实现组，这里使用大家经常称  
呼的名称吧，英文缩写叫 Code Group，简称 CG），总共加上我这个项目经理正好十个人，刚开始的时候客户  
（也就是旅行社，甲方）还是很乐意和我们每个组探讨，比如和需求组讨论需求，和美工讨论页面，和代码组讨  
论实现，告诉他们修改这里，删除这里，增加这些等等，这是一种比较常见的甲乙方合作模式，甲方深入到乙方  
的项目开发中，我们把这个模式用类图表示一下：

![这里写图片描述][SouthEast]

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

package com.alex.patterns.command;
    
    /** * @author Alex * 项目组分成了三个组，每个组还是要接受增删改的命令 */
    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.alex.patterns.command;
    
    /** * @author Alex * 需求组的职责是和客户谈定需求，这个组的人应该都是业务领域专家 */
    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.alex.patterns.command;
    
    /** * @author Alex * 美工组的职责是设计出一套漂亮、简单、便捷的界面 */
    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("客户要求页面变更计划...");
        }
    }

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

package com.alex.patterns.command;
    
    /** * @author Alex * 代码组的职责是实现业务逻辑，当然包括数据库设计了 */
    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("客户要求代码变更计划...");
        }
    }

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

package com.alex.patterns.command;
    
    /** * @author Alex * 客户就是甲方，给我们钱的一方，是老大 */
    public class Client { 
        public static void main(String[] args) {
            // 首先客户找到需求组说，过来谈需求，并修改
            System.out.println("-------------客户要求增加一个需求-----------------");
            Group rg = new RequirementGroup();
            // 找到需求组
            rg.find();
            // 增加一个需求
            rg.add();
            // 要求变更计划
            rg.plan();
        }
    }

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

package com.alex.patterns.command;
    
    /** * @author Alex * 客户就是甲方，给我们钱的一方，是老大 */
    public class Client1 { 
        public static void main(String[] args) {
            // 首先客户找到美工组说，过来谈页面，并修改
            System.out.println("-------------客户要求删除一个页面-----------------");
            Group pg = new PageGroup();
            // 找到需求组
            pg.find();
            // 去掉一个需求
            pg.delete();
            // 要求变更计划
            pg.plan();
        }
    }

好了，界面也谈过了，应该没什么大问题了吧。过了一天后，客户又让代码组过去，说是数据库设计问题，  
然后又叫美工过去，布置了一堆命令，这个我就不一一写了，大家应该能够体会到，你做过项目的话，这种体会  
更深，客户让修改你不修改？项目不想做了你!  
但是问题来了，我们修改可以，但是每次都是叫一个组去，布置个任务，然后出计划，次次都这样，如果让  
你当甲方也就是客户，你烦不烦？而且这种方式很容易出错误呀，而且还真发生过，客户把美工叫过去了，要删  
除，可美工说需求是这么写的，然后客户又命令需求组过去，一次次的折腾，客户也烦躁了，于是直接抓住我这  
个项目经理说：  
“我不管你们内部怎么安排，你就给我找个接头人，我告诉他怎么做，删除页面了，增加功能了，你们内部  
怎么处理，我就告诉他我要干什么就成了…”  
我一听，好呀，这也正是我想要的，我项目组的兄弟们也已经受不了了，于是我改变了一下我的处理方式，  
看看类图：

![这里写图片描述][SouthEast 1]

类图中增加了不少，看着也比较清晰，比较简单的（Command 抽象类与 Group 抽象类是没有关联关系的，  
与 Group 的三个实现类是有关联关系，为了线条不交叉就直接画上父类有关系），增加的几个类说明如下：  
Command 抽象类：客户发给我们的命令，定义三个工作组的成员变量，供子类使用；定义一个抽象方法  
execute，由子类来实现；  
Invoker 实现类:项目接头人，setComand 接受客户发给我我们的命令，action 方法是执行客户的命令  
（方法名写成是 action 是与 command 的 execute 区分开，避免混淆）  
我们先看 Command 抽象类代码：

package com.alex.patterns.command;
    
    
    /** * @author Alex * 命令的抽象类，我们把客户发出的命令定义成一个一个的对象 */
    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.alex.patterns.command;
    
    /** * @author Alex * 增加一项需求 */
    public class AddRequirementCommand extends Command { 
        // 执行增加一项需求的命令
        public void execute() {
            // 找到需求组
            super.rg.find();
            // 增加一份需求
            super.rg.add();
            // 给出计划
            super.rg.plan();
        }
    }

看删除一个页面的命令,DeletePageCommand 类：

package com.alex.patterns.command;
    
    /** * @author Alex * 删除一个页面的命令 */
    public class DeletePageCommand extends Command { 
        // 执行删除一个页面的命令
        public void execute() {
            // 找到页面组
            super.pg.find();
            // 删除一个页面
            super.rg.delete();
            // 给出计划
            super.rg.plan();
        }
    }

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

package com.alex.patterns.command;
    
    
    /** * @author Alex * 接头人的职责就是接收命令，并执行 */
    public class Invoker { 
        // 什么命令
        private Command command;
    
        // 客户发出命令
        public void setCommand(Command command) {
            this.command = command;
        }
    
        // 执行客户的命令
        public void action() {
            this.command.execute();
        }
    }

这个是更简单了，简单是简单，可以帮我们解决很多问题，我们再看一下客户提出变更的过程：

package com.alex.patterns.command;
    
    /** * @author Alex * 客户就是甲方，给我们钱的一方，是老大 */
    public class Client2 { 
        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.alex.patterns.command;
    
    
    /** * @author Alex * 客户就是甲方，给我们钱的一方，是老大 */
    public class Client4 { 
        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();
        }
    }

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

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

![这里写图片描述][SouthEast 2]

在这个类图中，我们看到三个角色：  
Receiver 角色：这个就是干活的角色，命令传递到这里是应该被执行的，具体到上面我们的例子中就是  
Group 的三个实现类；  
Command 角色：就是命令，需要我执行的所有命令都这里声明；  
Invoker 角色：调用者，接收到命令，并执行命令，例子中我这里项目经理就是这个角色；  
命令模式比较简单，但是在项目中使用是非常频繁的，封装性非常好，因为它把请求方（Invoker）和执  
行方（Receiver）分开了，扩展性也有很好的保障。但是，命令模式也是有缺点的，你看 Command 的子类没  
有，那个如果我要写下去的可不是几个，而是几十个，这个类膨胀的非常多，这个就需要大家在项目中自己考虑  
使用了。  
上面的例子我还没有说完， 我们想想， 客户要求增加一项需求， 那是不是页面也增加， 同时功能也要增加呢？  
如果不使用命令模式，客户就需要先找需求组，然后找美工组，然后找代码组，这个 … ，你想让客户跳楼呀！使  
用命令模式后，客户只管发命令模式，你增加一项需求，没问题，我内部调动三个组通力合作，然后反馈你结果，  
这也正是客户需要的， 那这个要怎么修改呢？想想看， 很简单的， 在 AddRequirementCommand 类的 execute  
方法中增加对 PageGroup 和 CodePage 的调用就成了，修改后的代码如下：

package com.alex.patterns.command;
    
    /** * @author Alex * 增加一项需求 */
    public class AddRequirementCommand1 extends Command { 
        // 执行增加一项需求的命令
        public void execute() {
            // 找到需求组
            super.rg.find();
            // 增加一份需求
            super.rg.add();
            // 页面也要增加
            super.pg.add();
            // 功能也要增加
            super.cg.add();
            // 给出计划
            super.rg.plan();
        }
    }

看看，是不是就解决问题了？命令模式做了一层非常好的封装。

[SouthEast]: /images/20220705/b8967023525c442ea4b94d0984726c81.png
[SouthEast 1]: /images/20220705/2753d3f1930949bc89a0126a80bace4e.png
[SouthEast 2]: /images/20220705/3fc5c50867174028878c38ddf421fa83.png