深入理解設計模式（十）命令模式

命令模式（command pattern）是一種資料驅動的設計模式，它屬於行為型模式。請求以命令的形式包裹在物件中，並傳給呼叫物件。呼叫物件尋找可以處理該命令的合適的物件，並把該命令傳給相應的物件，該物件執行命令。

命令模式是乙個高內聚的模式，其定義為：將乙個請求封裝成乙個物件，從而讓你使用不同的請求把客戶端引數化，對請求排隊或者記錄請求日誌，可以提供命令的撤銷和恢復功能。

在該類圖中，我們看到三個角色：

使用時機：當需要先將乙個函式登記上，然後再以後呼叫此函式時，就需要使用命令模式，其實這就是**函式。

有時候需要向某些物件傳送請求，但是並不知道請求的接收者是誰，也不知道被請求的操作是什麼。此時希望用一種松耦合的方式來設計程式，使得請求傳送者和請求接收者能夠消除彼此之間的耦合關係

例子

這個物件可以在程式中被四處傳遞，就像訂單可以從服務員手中傳到廚師的手中。這樣一來，客人不需要知道廚師的名字，從而解開了請求呼叫者和請求接收者之間的耦合關係

優點：缺點：

命令模式也是有缺點的，請看command的子類：如果有n個命令，問題就出來了，command的子類就可不是幾個，而是n個，這個類膨脹得非常大，這個就需要讀者在項目中慎重考慮使用。

receiver類，知道如何實施與執行乙個與請求相關的操作，任何類都可能作為乙個接受者

class
receiver
}

command類，用來宣告執行操作的介面

abstract
class
command
abstract
public
void
execute();
}

concretecommand類，將乙個接受者物件繫結於乙個動作，呼叫接受者相應的操作，以實現execute。

class
concretecommand : command
public
override
void
execute()
}

invoker類，要求該命令執行這個請求

class
invoker
public
void
executecommand()
}

客戶端**

static
void main(string
args)

命令模式的意圖是將乙個請求封裝成乙個物件，從而使您可以用不同的請求對客戶進行引數化。

命令模式主要解決的問題是在軟體系統中，行為請求者與行為實現者通常是一種緊耦合的關係，但某些場合，比如需要對行為進行記錄、撤銷或重做、事務等處理時，這種無法抵禦變化的緊耦合的設計就不太合適。

在某些場合，比如要對行為進行"記錄、撤銷/重做、事務"等處理，這種無法抵禦變化的緊耦合是不合適的。在這種情況下，如何將"行為請求者"與"行為實現者"解耦？將一組行為抽象為物件，可以實現二者之間的松耦合，這是命令模式的使用場景。

系統需要支援命令的撤銷(undo)操作和恢復(redo)操作，也可以考慮使用命令模式

命令模式的實現過程通過呼叫者呼叫接受者執行命令，順序：呼叫者→接受者→命令。

深入理解設計模式（十） 命令模式