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

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

1．使用命令模式作為"CallBack"在面向?qū)ο笙到y(tǒng)中的替代。"CallBack"講的便是先將一個(gè)函數(shù)登記上，然后在以后調(diào)用此函數(shù)。

2． 需要在不同的時(shí)間指定請(qǐng)求、將請(qǐng)求排隊(duì)。一個(gè)命令對(duì)象和原先的請(qǐng)求發(fā)出者可以有不同的生命期。換言之，原先的請(qǐng)求發(fā)出者可能已經(jīng)不在了，而命令對(duì)象本身仍 然是活動(dòng)的。這時(shí)命令的接收者可以是在本地，也可以在網(wǎng)絡(luò)的另外一個(gè)地址。命令對(duì)象可以在串形化之后傳送到另外一臺(tái)機(jī)器上去。

3．系統(tǒng)需要支持命令的撤消(undo)。命令對(duì)象可以把狀態(tài)存儲(chǔ)起來，等到客戶端需要撤銷命令所產(chǎn)生的效果時(shí)，可以調(diào)用undo()方法，把命令所產(chǎn)生的效果撤銷掉。命令對(duì)象還可以提供redo()方法，以供客戶端在需要時(shí)，再重新實(shí)施命令效果。

4．如果一個(gè)系統(tǒng)要將系統(tǒng)中所有的數(shù)據(jù)更新到日志里，以便在系統(tǒng)崩潰時(shí)，可以根據(jù)日志里讀回所有的數(shù)據(jù)更新命令，重新調(diào)用Execute()方法一條一條執(zhí)行這些命令，從而恢復(fù)系統(tǒng)在崩潰前所做的數(shù)據(jù)更新。
生活中的例子：
?????Command模式將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使你可以使用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化。用餐時(shí)的賬單是Command模式的一個(gè)例子。服務(wù)員接受顧客的點(diǎn)單，把它記在賬單上封裝。這個(gè)點(diǎn)單被排隊(duì)等待烹飪。注意這里的"賬單"是不依賴于菜單的，它可以被不同的顧客使用，因此它可以添入不同的點(diǎn)單項(xiàng)目。
???????????????????
代碼實(shí)現(xiàn)：
????在眾多的設(shè)計(jì)模式中，Command模式是很簡(jiǎn)單也很優(yōu)雅的一種設(shè)計(jì)模式。Command模式它封裝的是命令，把命令發(fā)出者的責(zé)任和命令執(zhí)行者的責(zé)任分開。我們知道，一個(gè)類是一組操作和相應(yīng)的一些變量的集合，現(xiàn)在有這樣一個(gè)類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?????///?恢復(fù)操作
37?
38?????///?</summary>
39?
40?????public?void?Redo()
41?
42?????{
43?????????Console.WriteLine("Redo");
44?????}
45?}

通常客戶端實(shí)現(xiàn)代碼如下：
???

?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?}

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

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

?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?????///?執(zhí)行
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?}

現(xiàn)在還需要一個(gè)Invoker角色的類，這其實(shí)相當(dāng)于一個(gè)中間角色，前面我曾經(jīng)說過，使用這樣的一個(gè)中間層也是我們經(jīng)常使用的手法，即把A對(duì)B的依賴轉(zhuǎn)換為A對(duì)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?現(xiàn)在再來看客戶程序的調(diào)用代碼：
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對(duì)這些命令進(jìn)行了封裝，使用它的一個(gè)關(guān)鍵就是抽象的Command類，它定義了一個(gè)操作的接口。同時(shí)我們也可以看到，本來這三個(gè)命令僅僅是三個(gè)方法而已，但是通過Command模式卻把它們提到了類的層面，這其實(shí)是違背了面向?qū)ο蟮脑瓌t，但它卻優(yōu)雅的解決了分離命令的請(qǐng)求者和命令的執(zhí)行者的問題，在使用Command模式的時(shí)候，一定要判斷好使用它的時(shí)機(jī)。

Command實(shí)現(xiàn)要點(diǎn)：

1．Command模式的根本目的在于將“行為請(qǐng)求者”與“行為實(shí)現(xiàn)者”解耦，在面向?qū)ο笳Z言中，常見的實(shí)現(xiàn)手段是“將行為抽象為對(duì)象”。

2．實(shí)現(xiàn)Command接口的具體命令對(duì)象ConcreteCommand有時(shí)候根據(jù)需要可能會(huì)保存一些額外的狀態(tài)信息。

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

4．Command模式與C#中的Delegate有些類似。但兩者定義行為接口的規(guī)范有所區(qū)別：Command以面向?qū)ο笾械摹敖涌?實(shí)現(xiàn)”來定義行為接口規(guī)范，更嚴(yán)格，更符合抽象原則；Delegate以函數(shù)簽名來定義行為接口規(guī)范，更靈活，但抽象能力比較弱。

5．使用命令模式會(huì)導(dǎo)致某些系統(tǒng)有過多的具體命令類。某些系統(tǒng)可能需要幾十個(gè)，幾百個(gè)甚至幾千個(gè)具體命令類，這會(huì)使命令模式在這樣的系統(tǒng)里變得不實(shí)際。
Command的優(yōu)缺點(diǎn)：

命令允許請(qǐng)求的一方和接收請(qǐng)求的一方能夠獨(dú)立演化，從而且有以下的優(yōu)點(diǎn)：

?

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

??? 2.允許接收請(qǐng)求的一方?jīng)Q定是否要否決（Veto）請(qǐng)求。

??? 3.能較容易地設(shè)計(jì)-個(gè)命令隊(duì)列。

??? 4.可以容易地實(shí)現(xiàn)對(duì)請(qǐng)求的Undo和Redo。

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

??? 6.命令模式把請(qǐng)求一個(gè)操作的對(duì)象與知道怎么執(zhí)行一個(gè)操作的對(duì)象分割開。

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

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

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

?

命令模式的缺點(diǎn)如下：

????1.使用命令模式會(huì)導(dǎo)致某些系統(tǒng)有過多的具體命令類。某些系統(tǒng)可能需要幾十個(gè)，幾百個(gè)甚至幾千個(gè)具體命令類，這會(huì)使命令模式在這樣的系統(tǒng)里變得不實(shí)際。
?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?}

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。