命令模式 命令模式很好理解，舉個例子，司令員下令讓士兵去幹件事情，從整個事情的角度來考慮，司令員的作用是，發出口令，口令經過傳遞，傳到了士兵耳朵裡，士兵去執行。這個過程好在，三者相互解耦，任何一方都不用去依賴其他人，只需要做好自己的事兒就行，司令員要的是結果，不會去關注到底士兵是怎麼實現的。我們看看關係圖：
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其實就是一種將請求和呈現分離的技術，其中必然涉及命令模式的思想！
介紹 意圖：將一個請求封裝成一個物件，從而使您可以用不同的請求對客戶進行引數化。
主要解決：在軟體系統中，行為請求者與行為實現者通常是一種緊耦合的關係，但某些場合，比如需要對行為進行記錄、撤銷或重做、事務等處理時，這種無法抵禦變化的緊耦合的設計就不太合適。
何時使用：在某些場合，比如要對行為進行"記錄、撤銷/重做、事務"等處理，這種無法抵禦變化的緊耦合是不合適的。在這種情況下，如何將"行為請求者"與"行為實現者"解耦？將一組行為抽象為物件，可以實現二者之間的鬆耦合。
如何解決：通過呼叫者呼叫接受者執行命令，順序：呼叫者→接受者→命令。
關鍵程式碼：
定義三個角色：
- 1、received 真正的命令執行物件
- 2、Command
- 3、invoker 使用命令物件的入口
應用
例項：struts 1 中的 action 核心控制器 ActionServlet 只有一個，相當於 Invoker，而模型層的類會隨著不同的應用有不同的模型類，相當於具體的 Command。
優點： 1、降低了系統耦合度。2、新的命令可以很容易新增到系統中去。
缺點：使用命令模式可能會導致某些系統有過多的具體命令類。
使用場景：認為是命令的地方都可以使用命令模式，
比如： 1、GUI 中每一個按鈕都是一條命令。
2、模擬 CMD。
注意事項：系統需要支援命令的撤銷(Undo)操作和恢復(Redo)操作，也可以考慮使用命令模式，見命令模式的擴充套件。