在閻宏博士的《JAVA與模式》一書中開頭是這樣描述命令（Command）模式的：命令模式屬於對象的行為模式。命令模式又稱為行動(Action)模式或交易(Transaction)模式。命令模式把一個請求或者操作封裝到一個對象中。命令模式允許系統使用不同的請求把客戶端參數化，對請求排隊或者記錄請求日誌，可以提供命令的撤銷和恢復功能。
命令模式通過將用戶的請求以命令對象的形式進行分裝，然後將命令發送給具體的調用處理者。命令模式把發出命令的責任和執行命令的責任分割開，委派給不同的對象，因而達到命令的發送者和命令執行者之間的解耦。
UML圖
命令模式涉及到的五個角色：
抽象命令角色（Command）：定義聲明所有命令指令類的規範行為。
具體命令角色（ConcreteCommand）：定義一個具體的命令角色，一般包含一個命令接受者的引用，通過在execute方法中調用具體的執行者進行執行。
接受者角色（Receiver）：該類負責具體實施或執行一個請求，充當了具體邏輯處理角色。
請求者角色（Invoker）：該類負責調用命令對象執行具體請求，相關的方法叫行動方法。
UML圖不是固定的，在實際使用的過程中可隨機應變，比如可以直接把Receiver定義成一個通用化的接受者來處理多個命令，或者通過工廠方法模式結合來處理多個命令的情況。
案例演示
我們都知道在小遊戲中都存在上、下、左、右的操作指令，所以這次我們就以這種場景來模擬。
創建抽象Command指令和具體的指令
定義接受者Receiver
定義請求者角色Invoker
定義客戶端
上面就是一個命令模式的演示，在上面的模式中，通過繼承實現多個對應類型的接收者，這裡同樣可以在一個接收者中完成。
優缺點
優點
類間解耦：調用者角色與接收者角色之間沒有任何依賴關係，調用者實現功能時只需調用Command 抽象類的execute方法就可以，不需要了解到底是哪個接收者執行。在我的理解中，可以直接把Receiver在Command中指定好，而不一定要在客戶端進行動態綁定。這樣或許會省事一些，但是擴展性需要考慮。
可擴展性：Command的子類可以非常容易地擴展，而調用者Invoker和高層次的模塊Client不產生嚴 重的代碼耦合。
命令模式結合其他模式會更優秀：命令模式可以結合責任鏈模式，實現命令族解析任務；結合模板方法模式，則可以減少 Command子類的膨脹問題。
缺點
命令模式也是有缺點的，如果有N個命令，問題就出來 了，Command的子類就可不是幾個，而是N個，這個類膨脹得非常大，這個就需要讀者在項 目中慎重考慮使用。
閱讀更多 Andoter的學習筆記 的文章
