Java設計模式——命令模式

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

 Invoker是調用者（司令員），

Receiver是被調用者（士兵），

MyCommand是命令，

實現了Command接口，持有接收對象，看實現代碼： 

 public interface Command

 {

      public void exe();

 } 

     public class MyCommand implements Command 

{ 

    private Receiver receiver; 

    public MyCommand(Receiver receiver)

 { 

      this.receiver = receiver;

 } 

      @Override public void exe() 

{ 

       receiver.action(); 

 } 

 } 

      public class Receiver 

{ 

     public void action()

{ 

     System.out.println("command received!");

 }  

}

      public class Invoker 

{

      private Command command;

      public Invoker(Command command)

 { 

       this.command = command; 

 }

      public void action(){ command.exe();

 }

 } 

      public class Test { public static void main(String[] args) 

{ 

    Receiver receiver = new Receiver(); 

    Command cmd = new MyCommand(receiver); 

     Invoker invoker = new Invoker(cmd); invoker.action();

 }

 } 

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

 介紹 意圖：將一個請求封裝成一個對象，從而使您能夠用不一樣的請求對客戶進行參數化。

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

什麼時候使用：在某些場合，好比要對行爲進行"記錄、撤銷/重作、事務"等處理，這種沒法抵禦變化的緊耦合是不合適的。在這種狀況下，如何將"行爲請求者"與"行爲實現者"解耦？將一組行爲抽象爲對象，能夠實現兩者之間的鬆耦合。  

如何解決：經過調用者調用接受者執行命令，順序：調用者→接受者→命令。

 關鍵代碼：

定義三個角色：

• 一、received 真正的命令執行對象
  
•  二、Command 
  
• 三、invoker 使用命令對象的入口 應用
  

實例：struts 1 中的 action 核心控制器 ActionServlet 只有一個，至關於 Invoker，而模型層的類會隨着不一樣的應用有不一樣的模型類，至關於具體的 Command。 

優勢： 一、下降了系統耦合度。
           二、新的命令能夠很容易添加到系統中去。

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

 使用場景：認爲是命令的地方均可以使用命令模式，

好比： 一、GUI 中每個按鈕都是一條命令。

            二、模擬 CMD。

 注意事項：系統須要支持命令的撤銷(Undo)操做和恢復(Redo)操做，也能夠考慮使用命令模式，見命令模式的擴展。