|
|
耦合與變化
耦合是軟件不能抵御變化災難的根本性原因。不僅實體對象與實體對象之間存在耦合關系，實體對象與行為操作之間也存在耦合關系。
創(chuàng)建型設計模式解決的創(chuàng)建者和被創(chuàng)建對象的耦合問題；
結構型設計模式解決的是實體對象和實體對象的耦合問題；
行為型設計模式解決的是實體對象和行為操作之間的耦合問題。
動機（Motivation）
在軟件構建過程中，“行為請求者”與“行為實現(xiàn)者”通常呈現(xiàn)一種“緊耦合”。但在某些場合——比如需要對行為進行“記錄、撤銷/重做（undo/redo）、事務”等處理，這種無法抵御變化的緊耦合是不合適的。在這種情況下，如何將“行為請求者”與“行為實現(xiàn)者”解耦？將一組行為抽象為對象，可以實現(xiàn)二者之間的松耦合。
意圖（Intent）
將一個請求封裝為一個對象，從而使你可用不同的請求對客戶（客戶程序，也是行為的請求者）進行參數(shù)化；對請求排隊或記錄請求日志，以及支持可撤銷的操作。
——《設計模式》GoF
例說Command應用
這種寫法一般情況是沒有問題，但是現(xiàn)在假設我們需要將這個操作進行日志記錄或者是增加撤銷方法，我們就沒辦法集中地來處理。Command模式并不是對Document類或Graphics類進行抽象，而是對他們里面的Show方法進行抽象。
這里Command既可以是抽象類，也可以是接口，其實寫成接口更好一點，因為C#支持接口的多繼承，而且Command里面的方法一般是不會有默認實現(xiàn)。這里具體類的Show方法寫成virtual的好處是它的子類可以重寫Show方法。
客戶程序
對于這種設計，還有一點小小的問題，我們不能要求所有的類都必須去實現(xiàn)Command接口。而且這些繼承自Command的類違背了單一職責原則，它既扮演了行為對象的角色，又扮演了實體的實現(xiàn)者的角色。因此我們做了一些改進。
現(xiàn)在我們已經(jīng)把DocumentCommand當成一個行為對象來使用了。客戶程序不變。本來Application和Show是直接依賴的，現(xiàn)在通過一步一步改進，Application不依賴于任何Document里面的Show方法，它依賴于Command這個公有的抽象，Command的繼承類才和Document的方法發(fā)生依賴。
結構（Structure）
其中ConcreteCommand對應例子中的DocumentCommand、GraphicsCommand。Receiver對應Document、Graphics。Action方法不必和Command接口的Execute保持一致。Receiver可以和Command沒有太大關系，我們只不過用ConcreteCommand來表達Receiver中的某些行為需求。
Command模式的幾個要點
Command模式的根本目的在于將“行為請求者”與“行為實現(xiàn)者”解耦，在面向?qū)ο笳Z言中，常見的實現(xiàn)手段是“將行為抽象為對象”。實現(xiàn)Command接口的具體命令對象ConcreteCommand有時候根據(jù)需要可能會保存一些額外的狀態(tài)信息。
通過使用Composite模式，可以將多個“命令”封裝為一個“復合命令”MacroCommand。
Command模式與C#中的Delegate（Delegate是把函數(shù)指針抽象成了為一種可被調(diào)用的行為對象）有些類似。但兩者定義行為接口的規(guī)范有所區(qū)別：Command以面向?qū)ο笾械?ldquo;接口-實現(xiàn)”來定義行為接口規(guī)范，更嚴格，更符合抽象原則；Delegate以函數(shù)簽名來定義行為接口規(guī)范，更靈活，但抽象能力比較弱。
.NET架構中的Command
由于.NET有了Delegate，它很少很少用到Command。它只要需要用到行為抽象，它都用Delegate去做。因為這是Framework，這是和業(yè)務領域相關度不大的基礎建設層面，它是不太需要用到OO的層面。對于我們來說，我們建議更多地用Command去實現(xiàn)。
it知識庫：C#面向?qū)ο笤O計模式縱橫談：Command 命令模式，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
