技術標籤：C#教程c#

本筆記摘抄自：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去實現。
五、總結

命令模式是把一個操作或者行為抽象為一個獨立的物件，通過對命令的抽象化來使得發出命令的責任和執行命令的責任分隔開，也可以對獨立的命令物件進行

特殊操作，比如可以實現命令的撤銷和恢復功能。