c23種設(shè)計模式8命令模式

1、命令模式(Command Pattern) 耦合與變化： 耦合是軟件不能抵御變化災(zāi)難的根本性原因。不僅實體對象與實體對象之間存在耦合關(guān)系，實體對象與行為操作之間也存在耦合關(guān)系。 動機(Motivate): 在軟件系統(tǒng)中，“行為請求者”與“行為實現(xiàn)者”通常呈現(xiàn)一種“緊耦合”。但在某些場合，比如要對行為進行“記錄、撤銷/重做、事務(wù)”等處理，這種無法抵御變化的緊耦合是不合適的。 在這種情況下，如何將“行為請求者”與“行為實現(xiàn)者”解耦？將一組行為抽象為對象，可以實現(xiàn)二者之間的松耦合。意圖(Intent): 將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數(shù)化；對請求排隊或記錄請求日志，以及

2、支持可撤消的操作。 -設(shè)計模式GOF結(jié)構(gòu)圖(Struct): 適用性：1使用命令模式作為CallBack在面向?qū)ο笙到y(tǒng)中的替代。CallBack講的便是先將一個函數(shù)登記上，然后在以后調(diào)用此函數(shù)。2需要在不同的時間指定請求、將請求排隊。一個命令對象和原先的請求發(fā)出者可以有不同的生命期。換言之，原先的請求發(fā)出者可能已經(jīng)不在了，而命令對象本身仍然是活動的。這時命令的接收者可以是在本地，也可以在網(wǎng)絡(luò)的另外一個地址。命令對象可以在串形化之后傳送到另外一臺機器上去。3系統(tǒng)需要支持命令的撤消(undo)。命令對象可以把狀態(tài)存儲起來，等到客戶端需要撤銷命令所產(chǎn)生的效果時，可以調(diào)用undo()方法，把命令所產(chǎn)生

3、的效果撤銷掉。命令對象還可以提供redo()方法，以供客戶端在需要時，再重新實施命令效果。4如果一個系統(tǒng)要將系統(tǒng)中所有的數(shù)據(jù)更新到日志里，以便在系統(tǒng)崩潰時，可以根據(jù)日志里讀回所有的數(shù)據(jù)更新命令，重新調(diào)用Execute()方法一條一條執(zhí)行這些命令，從而恢復系統(tǒng)在崩潰前所做的數(shù)據(jù)更新。生活中的例子： Command模式將一個請求封裝為一個對象，從而使你可以使用不同的請求對客戶進行參數(shù)化。用餐時的賬單是Command模式的一個例子。服務(wù)員接受顧客的點單，把它記在賬單上封裝。這個點單被排隊等待烹飪。注意這里的賬單是不依賴于菜單的，它可以被不同的顧客使用，因此它可以添入不同的點單項目。 代碼實現(xiàn)： 在眾

4、多的設(shè)計模式中，Command模式是很簡單也很優(yōu)雅的一種設(shè)計模式。Command模式它封裝的是命令，把命令發(fā)出者的責任和命令執(zhí)行者的責任分開。我們知道，一個類是一組操作和相應(yīng)的一些變量的集合，現(xiàn)在有這樣一個類Document，如下： 1/23/文檔類45/67publicclassDocument8910/*/1112/顯示操作1314/1516publicvoidDisplay()171819Console.WriteLine(Display);202122/*/2324/撤銷操作2526/2728publicvoidUndo()293031Console.WriteLine(Undo);3

5、23334/*/3536/恢復操作3738/3940publicvoidRedo()414243Console.WriteLine(Redo);4445通?？蛻舳藢崿F(xiàn)代碼如下： 1classProgram234staticvoidMain(stringargs)567Documentdoc=newDocument();89doc.Display();1011doc.Undo();1213doc.Redo();1415這樣的使用本來是沒有任何問題的，但是我們看到在這個特定的應(yīng)用中，出現(xiàn)了Undo/Redo的操作，這時如果行為的請求者和行為的實現(xiàn)者之間還是呈現(xiàn)這樣一種緊耦合，就不太合適了。可以看到

6、，客戶程序是依賴于具體Document的命令（方法）的，引入Command模式，需要對Document中的三個命令進行抽象，這是Command模式最有意思的地方，因為在我們看來Display()，Undo()，Redo()這三個方法都應(yīng)該是Document所具有的，如果單獨抽象出來成一個命令對象，那就是把函數(shù)層面的功能提到了類的層面，有點功能分解的味道，我覺得這正是Command模式解決這類問題的優(yōu)雅之處，先對命令對象進行抽象： 1/23/抽象命令45/67publicabstractclassDocumentCommand8910Document_document;1112publicDoc

7、umentCommand(Documentdoc)131415this._document=doc;161718/*/1920/執(zhí)行2122/2324publicabstractvoidExecute();2526其他的具體命令類都繼承于該抽象類，如下： 示意性代碼如下：1/23/顯示命令45/67publicclassDisplayCommand:DocumentCommand8910publicDisplayCommand(Documentdoc)1112:base(doc)1314151617publicoverridevoidExecute()181920_document.Displ

8、ay();2122232425/*/2627/撤銷命令2829/3031publicclassUndoCommand:DocumentCommand323334publicUndoCommand(Documentdoc)3536:base(doc)3738394041publicoverridevoidExecute()424344_document.Undo();4546474849/*/5051/重做命令5253/5455publicclassRedoCommand:DocumentCommand565758publicRedoCommand(Documentdoc)5960:base(d

9、oc)6162636465publicoverridevoidExecute()666768_document.Redo();6970現(xiàn)在還需要一個Invoker角色的類，這其實相當于一個中間角色，前面我曾經(jīng)說過，使用這樣的一個中間層也是我們經(jīng)常使用的手法，即把A對B的依賴轉(zhuǎn)換為A對C的依賴。如下： 1/23/Invoker角色45/67publicclassDocumentInvoker8910DocumentCommand_discmd;1112DocumentCommand_undcmd;1314DocumentCommand_redcmd;1516publicDocumentInvok

10、er(DocumentCommanddiscmd,DocumentCommandundcmd,DocumentCommandredcmd)171819this._discmd=discmd;2021this._undcmd=undcmd;2223this._redcmd=redcmd;24252627publicvoidDisplay()282930_discmd.Execute();313233publicvoidUndo()343536_undcmd.Execute();373839publicvoidRedo()404142_redcmd.Execute();43444546現(xiàn)在再來看客

11、戶程序的調(diào)用代碼：47classProgram484950staticvoidMain(stringargs)51525354Documentdoc=newDocument();555657DocumentCommanddiscmd=newDisplayCommand(doc);5859DocumentCommandundcmd=newUndoCommand(doc);6061DocumentCommandredcmd=newRedoCommand(doc);626364DocumentInvokerinvoker=newDocumentInvoker(discmd,undcmd,redcmd

12、);6566invoker.Display();6768invoker.Undo();6970invoker.Redo();717273可以看到在客戶程序中，不再依賴于Document的Display()，Undo()，Redo()命令，通過Command對這些命令進行了封裝，使用它的一個關(guān)鍵就是抽象的Command類，它定義了一個操作的接口。同時我們也可以看到，本來這三個命令僅僅是三個方法而已，但是通過Command模式卻把它們提到了類的層面，這其實是違背了面向?qū)ο蟮脑瓌t，但它卻優(yōu)雅的解決了分離命令的請求者和命令的執(zhí)行者的問題，在使用Command模式的時候，一定要判斷好使用它的時機。Com

13、mand實現(xiàn)要點：1Command模式的根本目的在于將“行為請求者”與“行為實現(xiàn)者”解耦，在面向?qū)ο笳Z言中，常見的實現(xiàn)手段是“將行為抽象為對象”。2實現(xiàn)Command接口的具體命令對象ConcreteCommand有時候根據(jù)需要可能會保存一些額外的狀態(tài)信息。3通過使用Compmosite模式，可以將多個命令封裝為一個“復合命令”MacroCommand。4Command模式與C#中的Delegate有些類似。但兩者定義行為接口的規(guī)范有所區(qū)別：Command以面向?qū)ο笾械摹敖涌?實現(xiàn)”來定義行為接口規(guī)范，更嚴格，更符合抽象原則；Delegate以函數(shù)簽名來定義行為接口規(guī)范，更靈活，但抽象能力比較

14、弱。5使用命令模式會導致某些系統(tǒng)有過多的具體命令類。某些系統(tǒng)可能需要幾十個，幾百個甚至幾千個具體命令類，這會使命令模式在這樣的系統(tǒng)里變得不實際。Command的優(yōu)缺點：命令允許請求的一方和接收請求的一方能夠獨立演化，從而且有以下的優(yōu)點： 1.命令模式使新的命令很容易地被加入到系統(tǒng)里。 2.允許接收請求的一方?jīng)Q定是否要否決（Veto）請求。 3.能較容易地設(shè)計-個命令隊列。 4.可以容易地實現(xiàn)對請求的Undo和Redo。 5.在需要的情況下，可以較容易地將命令記入日志。 6.命令模式把請求一個操作的對象與知道怎么執(zhí)行一個操作的對象分割開。 7.命令類與其他任何別的類一樣，可以修改和推廣。 8.你可以把命令對象聚合在一起，合成為合成命令。比如宏命令便是合成命令的例子。合成命令是合成模式的應(yīng)用。 9.由于加進新的具體命令類不影