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

1、命令模式(Command Pattern) 耦合與變化： 耦合是軟件不能抵御變化災(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)求日志，以及

2、支持可撤消的操作。 -設(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)生

3、的效果撤銷掉。命令對(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)： 在眾

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

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

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

13、mand實(shí)現(xiàn)要點(diǎn)：1Command模式的根本目的在于將“行為請(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。4Command模式與C#中的Delegate有些類似。但兩者定義行為接口的規(guī)范有所區(qū)別：Command以面向?qū)ο笾械摹敖涌?實(shí)現(xiàn)”來定義行為接口規(guī)范，更嚴(yán)格，更符合抽象原則；Delegate以函數(shù)簽名來定義行為接口規(guī)范，更靈活，但抽象能力比較

14、弱。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)新的具體命令類不影