技術標籤：一次性口令設計程式碼

命令模式

命令模式很好理解，舉個例子，司令員下令讓士兵去幹件事情，從整個事情的角度來考慮，司令員的作用是，發出口令，口令經過傳遞，傳到了士兵耳朵裡，士兵去執行。這個過程好在，三者相互解耦，任何一方都不用去依賴其他人，只需要做好自己的事兒就行，司令員要的是結果，不會去關注到底士兵是怎麼實現的。我們看看關係圖：

Invoker是呼叫者（司令員），Receiver是被呼叫者（士兵），MyCommand是命令，實現了Command介面，持有接收物件，看實現程式碼：

public 

這個很哈理解，命令模式的目的就是達到命令的發出者和執行者之間解耦，實現請求和執行分開，熟悉Struts的同學應該知道，Struts其實就是一種將請求和呈現分離的技術，其中必然涉及命令模式的思想！

介紹

意圖：將一個請求封裝成一個物件，從而使您可以用不同的請求對客戶進行引數化。

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

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

如何解決：通過呼叫者呼叫接受者執行命令，順序：呼叫者→接受者→命令。

關鍵程式碼：定義三個角色：1、received 真正的命令執行物件 2、Command 3、invoker 使用命令物件的入口

應用例項：struts 1 中的 action 核心控制器 ActionServlet 只有一個，相當於 Invoker，而模型層的類會隨著不同的應用有不同的模型類，相當於具體的 Command。

優點： 1、降低了系統耦合度。 2、新的命令可以很容易新增到系統中去。

缺點：使用命令模式可能會導致某些系統有過多的具體命令類。

使用場景：認為是命令的地方都可以使用命令模式，比如： 1、GUI 中每一個按鈕都是一條命令。 2、模擬 CMD。

注意事項：系統需要支援命令的撤銷(Undo)操作和恢復(Redo)操作，也可以考慮使用命令模式，見命令模式的擴充套件。

作者：No_Game_No_Life_