下面將對Java命令模式探討一二。首先，讓我們對命令模式進行一個簡單的理解。
Command 命令模式
Intent：
Encapsulate a request as an object , thereby letting you parameterize clIEnts with different requests, queue or log requests, and support undoable Operations.
瞎談：其實很好理解。命令模式，關心的就是命令(或者稱為操作)。打個比方。在一個公司裡面，整個運作就像一個系統。某個boss發布了一個命令，中層領導接到這個命令，然後指派給具體負責這個員工。整個流程很清晰吧。有一個需求，如何將這個流程固定下來，形成一個系統。我們只要抓住了重點：命令。將它抽取出來，其他的都迎刃而解了。抽取出命令，封裝成一個獨立的對象，實現了解耦。至於其他的，可以方便地擴展，不論這個命令是CEO，人事部，還是你爸提出來的。無論這個命令的執行者是張三還是王八。這個模式的產生，其實是哲學上的“抓住主要矛盾”。更多的例子，如其他作家舉的“去路邊吃烤肉和去烤肉店吃烤肉有什麼不同”或者“美猴王大鬧天宮中玉帝拍太白金星捉來猴子”。
正經：命令模式把一個請求或者操作封裝到一個對象中。命令模式運行系統使用不同的請求把客戶端參數化，對請求排隊或者記錄請求日志，可以提供命令的撤銷和恢復功能。
Java命令模式本質是對命令的封裝，從而把發出命令的責任和執行命令的責任分割開了，委派給不同的對象。通俗地說，我是老總，我只管發個命令，至於這個命令發給誰，誰執行，關我P事，我發錢請人不是為了給自己找麻煩。你是負責事情的員工，你的天職是做好上級交給你的任務，踏踏實實，不要知道太多，不要八卦，不要問太多了。
好處：
◆很容易構造一個命令隊列
◆記錄相關的命令日志
◆增加命令的狀態，實現命令的撤銷和重做
◆允許接受請求的一方決定是否可做
◆新的命令輕而易舉可以加入其中
缺點：可能會有過多的具體命令類存在
實現：
也不難，第一步關鍵是建立Command對象。擁有點面向對象的思想，就知道把它先抽象，讓繼承它的對象去具體實現。ClIEnt對象是發布命令的。Invoker對象是傳遞命令的，就是跑腿的。Receiver是受氣包，底層最累的程序員，負責干活吧。看看下面的類圖就清晰了：
上面的類圖，一開始我有一些疑問，不如Invoker為什麼要存在。現在想通了，ClIEnt的職責只是發布命令，就不要給它增加傳遞命令的職責。因為客戶有千千萬萬。在現實中，跑腿的人為什麼要存在呢?因為領導之所以是領導，就是只發表命令，跑腿等差事就給跑腿之人去辦吧。現實中，跑腿之人通常比做事之人混得要好些。因為他們之間面對的是領導，把做事之人功勞攬到自己身上。唉，沒想到設計模式蘊含了如此深刻的道理，佩服“設計模式的四人幫Gof”
Java命令模式實現例子：
閻宏博士的書中舉了很多生動有趣的例子，大家可以去查閱。比如一個Mp3。你按了一個播放鍵盤，就播放了。這就可以算是命令模式的一種。 你是ClIEnt ，按鍵是Invoker，mp3是Receiver，播放就是一個命令Command對象。
