耦合與變化：
??? 耦合是軟件不能抵御變化災難的根本性原因。不僅實體對象與實體對象之間存在耦合關系，實體對象與行為操作之間也存在耦合關系。?????????????????????????????????????????????????????????????????????????????????????????????
動機(Motivate):
????在軟件系統中，“行為請求者”與“行為實現者”通常呈現一種“緊耦合”。但在某些場合，比如要對行為進行“記錄、撤銷/重做、事務”等處理，這種無法抵御變化的緊耦合是不合適的。
????在這種情況下，如何將“行為請求者”與“行為實現者”解耦？將一組行為抽象為對象，可以實現二者之間的松耦合。

意圖(Intent):
????將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支持可撤消的操作。
??? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ? ? -------《設計模式》GOF
結構圖(Struct):
??? ?? ?? ?? ???
適用性：

1．使用命令模式作為"CallBack"在面向對象系統中的替代。"CallBack"講的便是先將一個函數登記上，然后在以后調用此函數。

2． 需要在不同的時間指定請求、將請求排隊。一個命令對象和原先的請求發出者可以有不同的生命期。換言之，原先的請求發出者可能已經不在了，而命令對象本身仍 然是活動的。這時命令的接收者可以是在本地，也可以在網絡的另外一個地址。命令對象可以在串形化之后傳送到另外一臺機器上去。

3．系統需要支持命令的撤消(undo)。命令對象可以把狀態存儲起來，等到客戶端需要撤銷命令所產生的效果時，可以調用undo()方法，把命令所產生的效果撤銷掉。命令對象還可以提供redo()方法，以供客戶端在需要時，再重新實施命令效果。

4．如果一個系統要將系統中所有的數據更新到日志里，以便在系統崩潰時，可以根據日志里讀回所有的數據更新命令，重新調用Execute()方法一條一條執行這些命令，從而恢復系統在崩潰前所做的數據更新。
生活中的例子：
?????Command模式將一個請求封裝為一個對象，從而使你可以使用不同的請求對客戶進行參數化。用餐時的賬單是Command模式的一個例子。服務員接受顧客的點單，把它記在賬單上封裝。這個點單被排隊等待烹飪。注意這里的"賬單"是不依賴于菜單的，它可以被不同的顧客使用，因此它可以添入不同的點單項目。
???????????????????
代碼實現：
????在眾多的設計模式中，Command模式是很簡單也很優雅的一種設計模式。Command模式它封裝的是命令，把命令發出者的責任和命令執行者的責任分開。我們知道，一個類是一組操作和相應的一些變量的集合，現在有這樣一個類Document，如下：
??? ?? ???????????????????????????????

?1?///?<summary>
?2?
?3?///?文檔類
?4?
?5?///?</summary>
?6?
?7?public?class?Document
?8?
?9?{
10?????/**?<summary>
11?
12?????///?顯示操作
13?
14?????///?</summary>
15?
16?????public?void?Display()
17?
18?????{
19?????????Console.WriteLine("Display");
20?????}?
21?
22?????/**?<summary>
23?
24?????///?撤銷操作
25?
26?????///?</summary>
27?
28?????public?void?Undo()
29?
30?????{
31?????????Console.WriteLine("Undo");
32?????}
33?
34?????/**?<summary>
35?
36?????///?恢復操作
37?
38?????///?</summary>
39?
40?????public?void?Redo()
41?
42?????{
43?????????Console.WriteLine("Redo");
44?????}
45?}

通常客戶端實現代碼如下：
???

?1?class?Program
?2?
?3?{
?4?????static?void?Main(string[]?args)
?5?
?6?????{
?7?????????Document?doc?=?new?Document();
?8?
?9?????????doc.Display();
10?
11?????????doc.Undo();
12?
13?????????doc.Redo();
14?????}
15?}

這樣的使用本來是沒有任何問題的，但是我們看到在這個特定的應用中，出現了Undo/Redo的操作，這時如果行為的請求者和行為的實現者之間還是呈現這樣一種緊耦合，就不太合適了。可以看到，客戶程序是依賴于具體Document的命令（方法）的，引入Command模式，需要對Document中的三個命令進行抽象，這是Command模式最有意思的地方，因為在我們看來Display()，Undo()，Redo()這三個方法都應該是Document所具有的，如果單獨抽象出來成一個命令對象，那就是把函數層面的功能提到了類的層面，有點功能分解的味道，我覺得這正是Command模式解決這類問題的優雅之處，先對命令對象進行抽象：

??? ? ? ? ? ? ? ? ? ?? ??

?1?///?<summary>
?2?
?3?///?抽象命令
?4?
?5?///?</summary>
?6?
?7?public?abstract?class?DocumentCommand
?8?
?9?{
10?????Document?_document;
11?
12?????public?DocumentCommand(Document?doc)
13?
14?????{
15?????????this._document?=?doc;
16?????}
17?
18?????/**?<summary>
19?
20?????///?執行
21?
22?????///?</summary>
23?
24?????public?abstract?void?Execute();
25?
26?}

其他的具體命令類都繼承于該抽象類，如下：
??? ???? ??? ??? ??? ??
示意性代碼如下：

?1?///?<summary>
?2?
?3?///?顯示命令
?4?
?5?///?</summary>
?6?
?7?public?class?DisplayCommand?:?DocumentCommand
?8?
?9?{
10?????public?DisplayCommand(Document?doc)
11?
12?????????:?base(doc)
13?????{????
14?
15?????}
16?
17?????public?override?void?Execute()
18?
19?????{
20?????????_document.Display();???
21?????}
22?}
23?
24?
25?/**?<summary>
26?
27?///?撤銷命令
28?
29?///?</summary>
30?
31?public?class?UndoCommand?:?DocumentCommand
32?
33?{?
34?????public?UndoCommand(Document?doc)
35?
36?????????:?base(doc)
37?????{???
38?
39?????}
40?
41?????public?override?void?Execute()
42?
43?????{
44?????????_document.Undo();???
45?????}
46?}
47?
48?
49?/**?<summary>
50?
51?///?重做命令
52?
53?///?</summary>
54?
55?public?class?RedoCommand?:?DocumentCommand
56?
57?{
58?????public?RedoCommand(Document?doc)
59?
60?????????:?base(doc)
61?????{?
62?
63?????}
64?
65?????public?override?void?Execute()
66?
67?????{
68?????????_document.Redo();???
69?????}?
70?}

現在還需要一個Invoker角色的類，這其實相當于一個中間角色，前面我曾經說過，使用這樣的一個中間層也是我們經常使用的手法，即把A對B的依賴轉換為A對C的依賴。如下：
??? ?? ???

?1?///?<summary>
?2?
?3?///?Invoker角色
?4?
?5?///?</summary>
?6?
?7?public?class?DocumentInvoker
?8?
?9?{
10?????DocumentCommand?_discmd;
11?
12?????DocumentCommand?_undcmd;
13?
14?????DocumentCommand?_redcmd;
15?
16?????public?DocumentInvoker(DocumentCommand?discmd,DocumentCommand?undcmd,DocumentCommand?redcmd)
17?????{
18?
19?????????this._discmd?=?discmd;
20?
21?????????this._undcmd?=?undcmd;
22?
23?????????this._redcmd?=?redcmd;
24?
25?????}
26?
27?????public?void?Display()
28?
29?????{
30?????????_discmd.Execute();
31?????}
32?
33?????public?void?Undo()
34?
35?????{
36?????????_undcmd.Execute();
37?????}
38?
39?????public?void?Redo()
40?
41?????{
42?????????_redcmd.Execute();
43?????}
44?}
45?
46?現在再來看客戶程序的調用代碼：
47?class?Program
48?
49?{
50?????static?void?Main(string[]?args)
51?
52?????{
53?
54?????????Document?doc?=?new?Document();
55?
56?
57?????????DocumentCommand?discmd?=?new?DisplayCommand(doc);
58?
59?????????DocumentCommand?undcmd?=?new?UndoCommand(doc);
60?
61?????????DocumentCommand?redcmd?=?new?RedoCommand(doc);
62?
63?
64?????????DocumentInvoker?invoker?=?new?DocumentInvoker(discmd,undcmd,redcmd);
65?
66?????????invoker.Display();
67?
68?????????invoker.Undo();
69?
70?????????invoker.Redo();
71?
72?????}
73?}

?

可以看到在客戶程序中，不再依賴于Document的Display()，Undo()，Redo()命令，通過Command對這些命令進行了封裝，使用它的一個關鍵就是抽象的Command類，它定義了一個操作的接口。同時我們也可以看到，本來這三個命令僅僅是三個方法而已，但是通過Command模式卻把它們提到了類的層面，這其實是違背了面向對象的原則，但它卻優雅的解決了分離命令的請求者和命令的執行者的問題，在使用Command模式的時候，一定要判斷好使用它的時機。

Command實現要點：

1．Command模式的根本目的在于將“行為請求者”與“行為實現者”解耦，在面向對象語言中，常見的實現手段是“將行為抽象為對象”。

2．實現Command接口的具體命令對象ConcreteCommand有時候根據需要可能會保存一些額外的狀態信息。

3．通過使用Compmosite模式，可以將多個命令封裝為一個“復合命令”MacroCommand。

4．Command模式與C#中的Delegate有些類似。但兩者定義行為接口的規范有所區別：Command以面向對象中的“接口-實現”來定義行為接口規范，更嚴格，更符合抽象原則；Delegate以函數簽名來定義行為接口規范，更靈活，但抽象能力比較弱。

5．使用命令模式會導致某些系統有過多的具體命令類。某些系統可能需要幾十個，幾百個甚至幾千個具體命令類，這會使命令模式在這樣的系統里變得不實際。
Command的優缺點：

命令允許請求的一方和接收請求的一方能夠獨立演化，從而且有以下的優點：

?

??? 1.命令模式使新的命令很容易地被加入到系統里。

??? 2.允許接收請求的一方決定是否要否決（Veto）請求。

??? 3.能較容易地設計-個命令隊列。

??? 4.可以容易地實現對請求的Undo和Redo。

??? 5.在需要的情況下，可以較容易地將命令記入日志。

??? 6.命令模式把請求一個操作的對象與知道怎么執行一個操作的對象分割開。

??? 7.命令類與其他任何別的類一樣，可以修改和推廣。

??? 8.你可以把命令對象聚合在一起，合成為合成命令。比如宏命令便是合成命令的例子。合成命令是合成模式的應用。

??? 9.由于加進新的具體命令類不影響其他的類，因此增加新的具體命令類很容易。
?

?

命令模式的缺點如下：

????1.使用命令模式會導致某些系統有過多的具體命令類。某些系統可能需要幾十個，幾百個甚至幾千個具體命令類，這會使命令模式在這樣的系統里變得不實際。
?1?class?Program
?2?
?3?{
?4?????static?void?Main(string[]?args)
?5?
?6?????{
?7?????????Document?doc?=?new?Document();
?8?
?9?????????doc.Display();
10?
11?????????doc.Undo();
12?
13?????????doc.Redo();
14?????}
15?}

總結

以上是生活随笔為你收集整理的32命令模式(Command Pattern)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。