15.設計模式_命令模式
一、前言
之前一直在忙於工作上的事情，關於設計模式系列一直沒更新，最近項目中發現，對於設計模式的了解是必不可少的，當然對於設計模式的應用那更是重要，可以說是否懂得應用設計模式在項目中是衡量一個程序員的技術水平，因為對於一個功能的實現，高級工程師和初級工程師一樣都會實現，但是區別在於它們實現功能的可擴展和可維護性，也就是代碼的是否“優美”、可讀。但是，要更好地應用，首先就必須了解各種設計模式和其應用場景，所以我還是希望繼續完成設計模式這個系列，希望通過這種總結的方式來加深自己設計模式的理解。
二、命令模式的介紹
2.1 命令模式的定義
命令模式屬於對象的行為型模式。命令模式是把一個操作或者行為抽象為一個對象中，通過對命令的抽象化來使得發出命令的責任和執行命令的責任分隔開。命令模式的實現可以提供命令的撤銷和恢復功能。
2.2 命令模式的結構
既然，命令模式是實現把發出命令的責任和執行命令的責任分割開，然而中間必須有某個對象來幫助發出命令者來傳達命令，使得執行命令的接收者可以收到命令並執行命令。例如，開學了，院領導說計算機學院要進行軍訓，計算機學院的學生要跑1000米，院領導的話也就相當於一個命令，他不可能直接傳達給到學生，他必須讓教官來發出命令，並監督學生執行該命令。在這個場景中，發出命令的責任是屬於學院領導，院領導充當與命令發出者的角色，執行命令的責任是屬於學生，學生充當於命令接收者的角色，而教官就充當於命令的發出者或命令請求者的角色，然而命令模式的精髓就在於把每個命令抽象為對象。從而命令模式的結構如下圖所示：
從命令模式的結構圖可以看出，它涉及到五個角色，它們分別是：
- 客戶角色：發出一個具體的命令並確定其接受者。
- 命令角色：聲明了一個給所有具體命令類實現的抽象接口
- 具體命令角色：定義了一個接受者和行為的弱耦合，負責調用接受者的相應方法。
- 請求者角色：負責調用命令對象執行命令。
- 接受者角色：負責具體行為的執行。
2.3 命令模式的實現
現在，讓我們以上面的軍訓的例子來實現一個命令模式，在實現之前，可以參考下命令模式的結構圖來分析下實現過程。
軍訓場景中，具體的命令即是學生跑1000米，這裏學生是命令的接收者，教官是命令的請求者，院領導是命令的發出者，即客戶端角色。要實現命令模式，則必須需要一個抽象命令角色來聲明約定，這裏以抽象類來來表示。命令的傳達流程是：
命令的發出者必須知道具體的命令、接受者和傳達命令的請求者，對應於程序也就是在客戶端角色中需要實例化三個角色的實例對象了。
命令的請求者負責調用命令對象的方法來保證命令的執行，對應於程序也就是請求者對象需要有命令對象的成員，並在請求者對象的方法內執行命令。
具體命令就是跑1000米，這自然屬於學生的責任，所以是具體命令角色的成員方法，而抽象命令類定義這個命令的抽象接口。
有了上面的分析之後，具體命令模式的實現代碼如下所示：
1
2 // 教官，負責調用命令對象執行請求
3 public class Invoke
4 {
5 public Command _command;
6
7 public Invoke(Command command)
8 {
9 this._command = command;
10 }
11
12 public void ExecuteCommand()
13 {
14 _command.Action();
15 }
16 }
17
18 // 命令抽象類
19 public abstract class Command
20 {
21 // 命令應該知道接收者是誰，所以有Receiver這個成員變量
22 protected Receiver _receiver;
23
24 public Command(Receiver receiver)
25 {
26 this._receiver = receiver;
27 }
28
29 // 命令執行方法
30 public abstract void Action();
31 }
32
33 //
34 public class ConcreteCommand :Command
35 {
36 public ConcreteCommand(Receiver receiver)
37 : base(receiver)
38 {
39 }
40
41 public override void Action()
42 {
43 // 調用接收的方法，因為執行命令的是學生
44 _receiver.Run1000Meters();
45 }
46 }
47
48 // 命令接收者——學生
49 public class Receiver
50 {
51 public void Run1000Meters()
52 {
53 Console.WriteLine("跑1000米");
54 }
55 }
56
57 // 院領導
58 class Program
59 {
60 static void Main(string[] args)
61 {
62 // 初始化Receiver、Invoke和Command
63 Receiver r = new Receiver();
64 Command c = new ConcreteCommand(r);
65 Invoke i = new Invoke(c);
66
67 // 院領導發出命令
68 i.ExecuteCommand();
69 }
70 }
三、.NET中命令模式的應用(引用TerryLee)
在ASP.NET的MVC模式中，有一種叫Front Controller的模式，它分為Handler和Command樹兩個部分，Handler處理所有公共的邏輯，接收HTTP Post或Get請求以及相關的參數並根據輸入的參數選擇正確的命令對象，然後將控制權傳遞到Command對象，由其完成後面的操作，這裏面其實就是用到了Command模式。
Front Controller 的處理程序部分結構圖
Front Controller的命令部分結構圖
Handler 類負責處理各個 Web 請求，並將確定正確的 Command 對象這一職責委派給 CommandFactory 類。當 CommandFactory 返回 Command 對象後，Handler 將調用 Command 上的 Execute 方法來執行請求。具體的實現如下
View Code
四、命令模式的適用場景
在下面的情況下可以考慮使用命令模式：
- 系統需要支持命令的撤銷（undo）。命令對象可以把狀態存儲起來，等到客戶端需要撤銷命令所產生的效果時，可以調用undo方法吧命令所產生的效果撤銷掉。命令對象還可以提供redo方法，以供客戶端在需要時，再重新實現命令效果。
- 系統需要在不同的時間指定請求、將請求排隊。一個命令對象和原先的請求發出者可以有不同的生命周期。意思為：原來請求的發出者可能已經不存在了，而命令對象本身可能仍是活動的。這時命令的接受者可以在本地，也可以在網絡的另一個地址。命令對象可以串行地傳送到接受者上去。
- 如果一個系統要將系統中所有的數據消息更新到日誌裏，以便在系統崩潰時，可以根據日誌裏讀回所有數據的更新命令，重新調用方法來一條一條地執行這些命令，從而恢復系統在崩潰前所做的數據更新。
- 系統需要使用命令模式作為“CallBack(回調)”在面向對象系統中的替代。Callback即是先將一個方法註冊上，然後再以後調用該方法。
五、命令模式的優缺點
命令模式使得命令發出的一個和接收的一方實現低耦合，從而有以下的優點：
- 命令模式使得新的命令很容易被加入到系統裏。
- 可以設計一個命令隊列來實現對請求的Undo和Redo操作。
- 可以較容易地將命令寫入日誌。
- 可以把命令對象聚合在一起，合成為合成命令。合成命令式合成模式的應用。
命令模式的缺點：
- 使用命令模式可能會導致系統有過多的具體命令類。這會使得命令模式在這樣的系統裏變得不實際。
六、總結
命令模式的實現要點在於把某個具體的命令抽象化為具體的命令類，並通過加入命令請求者角色來實現將命令發送者對命令執行者的依賴分割開，在上面軍訓的例子中，如果不使用命令模式的話，則命令的發送者將對命令接收者是強耦合的關系，實現代碼如下：
1 // 院領導
2 class Program
3 {
4 static void Main(string[] args)
5 {
6 // 行為的請求者和行為的實現者之間呈現一種緊耦合關系
7 Receiver r = new Receiver();
8
9 r.Run1000Meters();
10 }
11 }
12
13 public class Receiver
14 {
15 // 操作
16 public void Run1000Meters()
17 {
18 Console.WriteLine("跑1000米");
19 }
20 }
到這裏，本章的內容就介紹結束了，在下一章將繼續為大家分享下我對叠代器模式的理解。
15.設計模式_命令模式