定義：命令模式就是將請求發出者和請求執行者進行分離，並且建立乙個中間類，來負責請求發出和執行的互動，這樣能降低系統耦合度，方便未來系統的更新和維護。
uml圖：
優點：
方便未來新命令的新增。
缺點：
使用命令模式可能會導致某些系統有過多的具體命令類。因為針對每乙個命令都需要設計乙個具體命令類，因此某些系統可能需要大量具體命令類，這將影響命令模式的使用。
適用場景：對一些需求容易改動的地方，場景又類似於這種
發出請求-執行 業務流程的，使用命令模式會帶來很多便利。
場景舉例：
有乙個指揮官今天需要命令三連去襲擊敵營,那麼設計可以為：
版本1
指揮官命令類command:
命令執行類 receiver
但是明天發布的命令可能不一樣,上面的設計無法滿足未來的需要,所以：
版本2
命令介面：command
命令實現類：concretecommand（
三連襲擊敵營）
命令接收者：receiver(三連)
這樣雖然可以滿足未來不定的需求，但是業務邏輯卻暴露了，應該將請求發出和請求執行的邏輯流程封裝起來，對外提供方法呼叫。所以最後為：
版本3
命令介面：command
命令實現類：concretecommand（
三連襲擊敵營）
命令接收者：receiver(三連)
客戶端呼叫者（業務邏輯封裝類）：invoker
**實現;
最近在學設計模式，收穫很多，現在嘗試著去總結一下，有些地方還是不能很好的表達出來，出入之處，還望指正。
設計模式學習 命令模式
命令模式，將乙個請求封裝為乙個物件，從而使你可以用不同的請求對客戶進行引數化，對請求排隊或記錄請求日誌，以及支援可撤銷操作。命令模式的作用 第一，它能較容易地設計乙個命令佇列 第二，在需要的情況下，可以較容易地將命令計入日誌 第三，允許接收請求的一方決定是否要否決請求。第四，可以容易地實現對請求的撤...
設計模式學習 命令模式
最近在看 headfirst設計模式 一書，正開始學習設計模式不久。哎，就大四了，感覺落後了別人很多，傷感。現在也只能一步乙個腳印，慢慢進步吧。其實，前面已經學過工廠模式 抽象工廠和工廠方法 觀察者模式 單件模式 策略模式。今天把命令模式看完了，看懂並不是很困難，我想困難的是如何在實際中運用它們。因...
Head First設計模式1 命令模式
命令模式 通過命令模式，可以使發出請求的物件與被請求的物件都依賴抽象程式設計，而非依賴具體的類，實現了解耦。並且由於較好的封裝了請求，命令模式可以被撤銷。package command inte ce icommand class light public void on public void o...