耦合與變化

　　耦合是軟件不能抵御變化災難的根本性原因。不僅實體對象與實體對象之間存在耦合關系，實體對象與行為操作之間也存在耦合關系。

　　創建型設計模式解決的創建者和被創建對象的耦合問題；

　　結構型設計模式解決的是實體對象和實體對象的耦合問題；

　　行為型設計模式解決的是實體對象和行為操作之間的耦合問題。

　　動機（Motivation）

　　在軟件構建過程中，“行為請求者”與“行為實現者”通常呈現一種“緊耦合”。但在某些場合——比如需要對行為進行“記錄、撤銷/重做（undo/redo）、事務”等處理，這種無法抵御變化的緊耦合是不合適的。在這種情況下，如何將“行為請求者”與“行為實現者”解耦？將一組行為抽象為對象，可以實現二者之間的松耦合。

　　意圖（Intent）

　　將一個請求封裝為一個對象，從而使你可用不同的請求對客戶（客戶程序，也是行為的請求者）進行參數化；對請求排隊或記錄請求日志，以及支持可撤銷的操作。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《設計模式》GoF

　　例說Command應用

　　這種寫法一般情況是沒有問題，但是現在假設我們需要將這個操作進行日志記錄或者是增加撤銷方法，我們就沒辦法集中地來處理。Command模式并不是對Document類或Graphics類進行抽象，而是對他們里面的Show方法進行抽象。

　　這里Command既可以是抽象類，也可以是接口，其實寫成接口更好一點，因為C#支持接口的多繼承，而且Command里面的方法一般是不會有默認實現。這里具體類的Show方法寫成virtual的好處是它的子類可以重寫Show方法。

　　客戶程序

　　對于這種設計，還有一點小小的問題，我們不能要求所有的類都必須去實現Command接口。而且這些繼承自Command的類違背了單一職責原則，它既扮演了行為對象的角色，又扮演了實體的實現者的角色。因此我們做了一些改進。

　　現在我們已經把DocumentCommand當成一個行為對象來使用了。客戶程序不變。本來Application和Show是直接依賴的，現在通過一步一步改進，Application不依賴于任何Document里面的Show方法，它依賴于Command這個公有的抽象，Command的繼承類才和Document的方法發生依賴。

　　結構（Structure）

　　其中ConcreteCommand對應例子中的DocumentCommand、GraphicsCommand。Receiver對應Document、Graphics。Action方法不必和Command接口的Execute保持一致。Receiver可以和Command沒有太大關系，我們只不過用ConcreteCommand來表達Receiver中的某些行為需求。

　　Command模式的幾個要點

　　Command模式的根本目的在于將“行為請求者”與“行為實現者”解耦，在面向對象語言中，常見的實現手段是“將行為抽象為對象”。實現Command接口的具體命令對象ConcreteCommand有時候根據需要可能會保存一些額外的狀態信息。

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

　　Command模式與C#中的Delegate（Delegate是把函數指針抽象成了為一種可被調用的行為對象）有些類似。但兩者定義行為接口的規范有所區別：Command以面向對象中的“接口-實現”來定義行為接口規范，更嚴格，更符合抽象原則；Delegate以函數簽名來定義行為接口規范，更靈活，但抽象能力比較弱。

　　.NET架構中的Command

　　由于.NET有了Delegate，它很少很少用到Command。它只要需要用到行為抽象，它都用Delegate去做。因為這是Framework，這是和業務領域相關度不大的基礎建設層面，它是不太需要用到OO的層面。對于我們來說，我們建議更多地用Command去實現。

it知識庫：C#面向對象設計模式縱橫談：Command 命令模式，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。