C#设计模式学习笔记：(14)命令模式

本笔记摘抄自：https://www.cnblogs.com/PatrickLiu/p/7873322.html，记录一下学习过程以备后续查用。

一、引言

今天我们要讲行为型设计模式的第二个模式--命令模式，又称为行动（Action）模式或交易（Transaction）模式，先从名字上来看。“命令模式”理解为一种

行为或者一个操作就是一个命令。“命令”这个词语在军队里面用的最多，比如：下达作战命令，接下来就是上战场玩命了。基于这些，命令就是任务，我们从

这个名字上并不知道命令的发出者和接受者分别是谁，为什么呢？因为我们并不关心他们是谁，发出命令的人发出命令，可以继续做其他的事情，接受命令

的人执行任务就可以，不需要你发出命令，还要监督我们完成，只要我们完成任务是合格的就行，这种行为也就是“解耦”。在我们的现实生活中有很多例子可

以拿来说明这个模式，我们还拿吃饺子这个事情来说。我的妈妈说了，今天想吃饺子（发出了命令），然后我妈妈就去看电视去了。我们夫妻俩收到命令就开

始和面、做饺子馅、包饺子。饺子包好了，到晚饭时间时我们开始烧水煮饺子，老妈按时吃上了饺子。还有很多例子，就不一一列举了。

    二、命令模式介绍

命令模式：英文名称--Command Pattern；分类--行为型。

2.1、动机（Motivate）

在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合--比如需要对行为进行“记录、撤销/重做（undo/redo）、事务”等处理，

这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。

    2.2、意图（Intent）

将一个请求封装为一个对象，从而使你可用不同的请求对客户（客户程序，也是行为的请求者）进行参数化；对请求排队或记录请求日志，以及支持可撤销

的操作。——《设计模式》GoF

    2.3、结构图（Structure）

2.4、模式的组成

从命令模式的结构图可以看出，它涉及到五个角色，它们分别是：

1）客户角色（Client）：创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，

把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。

2）命令角色（Command）：声明了一个给所有具体命令类实现的抽象接口。

3）具体命令角色（ConcreteCommand）：命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。

4）请求者角色（Invoker）：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作

的地方，也就是说相当于使用命令对象的入口。

5）接受者角色（Receiver）：接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。

2.5、命令模式的具体实现

下面以生活中吃饺子为例来说说如何实现命令模式吧。今天早上，我妈妈就发布了命令，说她老人家想吃猪肉大葱馅的饺子。由于我妈妈没见到我又要出去办

事，就让我爸爸捎个话给我们夫妻俩，晚上要吃猪肉大葱馅的饺子。我瞬间就明白了，这个伟大的任务就落到我们夫妻俩肩上了。说做就做，保证晚饭能吃上热

气腾腾的饺子，具体实现代码如下：

    class Program
    {
        /// <summary>
        /// 这个类型就是请求者角色--也就是我老爸的角色，告诉我，老妈要吃饺子。
        /// </summary>
        public sealed class PaPaInvoker
        {
            //老爸从老妈那里接受到的命令
            private Command _command;

            //老爸开始接受具体的命令
            public PaPaInvoker(Command command)
            {
                _command = command;
            }

            //老爸给我们下达命令
            public void ExecuteCommand()
            {
                _command.MakeDumplings();
            }
        }

        /// <summary>
        /// 该类型就是抽象命令角色--Commmand，定义了命令的抽象接口，任务是包饺子。
        /// </summary>
        public abstract class Command
        {
            //真正任务的接受者
            protected MeAndWife _worker;

            protected Command(MeAndWife worker)
            {
                _worker = worker;
            }

            //该方法就是抽象命令对象Command的Execute方法
            public abstract void MakeDumplings();
        }

        /// <summary>
        /// 该类型是具体命令角色--ConcreteCommand，这个命令完成制作“猪肉大葱馅”的饺子。
        /// </summary>
        public sealed class MakeDumplingsCommand : Command
        {
            public MakeDumplingsCommand(MeAndWife worker) : base(worker) { }

            //执行命令--包饺子
            public override void MakeDumplings()
            {
                _worker.Execute("今天包的是农家猪肉和农家大葱馅的饺子。");
            }
        }

        /// <summary>
        /// 该类型是具体命令接受角色Receiver，具体包饺子的行为是我们夫妻俩来完成的。
        /// </summary>
        public sealed class MeAndWife
        {
            //这个方法相当于Receiver类型的Action方法
            public void Execute(string job)
            {
                Console.WriteLine(job);
            }
        }

        static void Main(string[] args)
        {
            #region 命令模式
            //老妈想吃猪肉大葱馅的饺子
            MeAndWife meAndWife = new MeAndWife();                  //命令接受者
            Command command = new MakeDumplingsCommand(meAndWife);  //命令
            PaPaInvoker papa = new PaPaInvoker(command);            //命令请求者

            //老妈发布命令
            papa.ExecuteCommand();

            Console.Read();
            #endregion
        }
    }

运行结果如下：

这个模式有点复杂，刚开始也不是很好理解，这种模式在我们现实的编码中用的不是很多，可能针对特定领域的软件或者系统需求更大，比如：文档编辑等。

在编码过程中慢慢体会吧，仔细看看代码的结构和模式的使用场景。这个模式的也有一些变形，某些角色可以合并或者省略。我写的这个代码实现，没有突出命

令的Redo和Undo，也没写命令的排队，但是大家要知道，之所以把行为抽象独立对象，就是要对其可以进行特殊处理。

三、命令模式的实现要点

1）Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。

2）实现Command接口的具体命令对象ConcreteCommand，有时候根据需要可能会保存一些额外的状态信息。

3）通过使用Composite组合模式，可以将多个命令封装为一个“复合命令”MacroCommand。

4）Command模式与C#中的Delegate有些类似，但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，

更符合抽象原则；Delegate以函数签名来定义行为接口规范，更灵活，但抽象能力比较弱。

5）使用命令模式会导致某些系统有过多的具体命令类。某些系统可能需要几十、几百甚至几千个具体命令类，这会使命令模式在这样的系统里变得不实际。

3.1、命令模式的优点

1）命令模式使得新的命令很容易被加入到系统里。

2）可以设计一个命令队列来实现对请求的Undo和Redo操作。

3）可以较容易地将命令写入日志。

4）可以把命令对象聚合在一起，合成为合成命令。

3.2、命令模式的缺点

1）使用命令模式可能会导致系统有过多的具体命令类，这会使得命令模式在这样的系统里变得不实际。

3.3、命令模式的使用场景

1）系统需要支持命令的撤销（undo）。命令对象可以把状态存储起来，等到客户端需要撤销命令所产生的效果时，可以调用undo方法把命令所产生的效果撤

销掉。命令对象还可以提供redo方法，以供客户端在需要时，再重新实现命令效果。

2）系统需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命周期。意思为：原来请求的发出者可能已经不存在了，

而命令对象本身可能仍是活动的。这时命令的接受者可以在本地，也可以在网络的另一个地址。命令对象可以串行地传送到接受者上去。

3）如果一个系统要将系统中所有的数据消息更新到日志里，以便在系统崩溃时，可以根据日志里读回所有数据的更新命令，重新调用方法来一条一条地执行

这些命令，从而恢复系统在崩溃前所做的数据更新。

4）系统需要使用命令模式作为“CallBack(回调)”在面向对象系统中的替代。Callback即是先将一个方法注册上，然后再以后调用该方法。

四、.NET 中命令模式的实现

由于.NET有了Delegate，它很少很少用到Command。它只要需要用到行为抽象，它都用Delegate去做。因为这是Framework，这是和业务领域相关度不大的

基础建设层面，它是不太需要用到OO的层面。对于我们来说，我们建议更多地用Command去实现。

五、总结

命令模式是把一个操作或者行为抽象为一个独立的对象，通过对命令的抽象化来使得发出命令的责任和执行命令的责任分隔开，也可以对独立的命令对象进行

特殊操作，比如可以实现命令的撤销和恢复功能。