命令模式：將一個請求封裝為一個對象，從而使得你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支持可撤銷的操作【DP】

先看代碼吧：

Receiver:

package com.sjmx.command;

public class Receiver {
    public void doSomething(){  
        System.out.println("接受者-業務邏輯處理");  
    }  
}

Command:

package com.sjmx.command;

public abstract class Command {
     
 
public abstract void execute();  
}

ConcreteCommand:

package com.sjmx.command;

public class ConcreteCommand extends Command {

    private Receiver receiver;

    public ConcreteCommand(Receiver receiver) {
        this.receiver = receiver;
    }

    public void execute() {
        this.receiver.doSomething();
    }
}
 

Invoker:

package com.sjmx.command;

public class Invoker {
    private Command command;  
    public void setCommand(Command command) {  
        this.command = command;  
    }  
    public void action(){  
        this.command.execute();  
    }  
}

Client:

package com.sjmx.command;

public class
 
 Client {
    public static void main(String[] args) {
        Receiver receiver = new Receiver();
        Command command = new ConcreteCommand(receiver);
        // 客戶端直接執行具體命令方式（此方式與類圖相符）
        command.execute();

        
        // 客戶端通過調用者來執行命令
        Invoker invoker = new Invoker();
        invoker.setCommand(command);
        invoker.action();
    }
}

1. 解決的問題

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

2. 模式中角色

　　2.1 抽象命令（Command）：定義命令的接口，聲明執行的方法。

　　2.2 具體命令（ConcreteCommand）：具體命令，實現要執行的方法，它通常是“虛”的實現；通常會有接收者，並調用接收者的功能來完成命令要執行的操作。

　　2.3 接收者（Receiver）：真正執行命令的對象。任何類都可能成為一個接收者，只要能實現命令要求實現的相應功能。

　 2.4 調用者（Invoker）：要求命令對象執行請求，通常會持有命令對象，可以持有很多的命令對象。這個是客戶端真正觸發命令並要求命令執行相應操作的地方，也就是說相當於使用命令對象的入口。

　　2.5 客戶端（Client）：命令由客戶端來創建，並設置命令的接收者。

4 模式分析

　　　　4.1 本質：對命令進行封裝，將發出命令與執行命令的責任分開。

　　　　4.2 每一個命令都是一個操作：請求的一方發出請求，要求執行一個操作；接收的一方收到請求，並執行操作。

　　　　4.3 請求方和接收方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎麽被接收，以及操作是否被執行、何時被執行，以及是怎麽被執行的。

　　　　4.4 使請求本身成為一個對象，這個對象和其它對象一樣可以被存儲和傳遞。

　　　　4.5 命令模式的關鍵在於引入了抽象命令接口，且發送者針對抽象命令接口編程，只有實現了抽象命令接口的具體命令才能與接收者相關聯。　

5. 模式總結

　　5.1 優點

　　　　5.1.1 解除了請求者與實現者之間的耦合，降低了系統的耦合度。

　　　　5.1.2 對請求排隊或記錄請求日誌，支持撤銷操作。

　　　　5.1.3 可以容易地設計一個組合命令。

　　　　5.1.4 新命令可以容易地加入到系統中。

　　5.2 缺點

　　　　5.2.1 因為針對每一個命令都需要設計一個具體命令類，使用命令模式可能會導致系統有過多的具體命令類。

　　5.3 適用場景

　　　　5.3.1 當需要對行為進行“記錄、撤銷/重做”等處理時。

　　　　5.3.2 系統需要將請求者和接收者解耦，使得調用者和接收者不直接交互。

　　　　5.3.3 系統需要在不同時間指定請求、請求排隊和執行請求。

　　　　5.3.4 系統需要將一組操作組合在一起，即支持宏命令。

最近在搞微服務，其中hystrix技術底層代碼就用到了命令模式，有時間整理出來分享一下：

【行為型模式】《大話設計模式》——讀後感 （15）烤羊肉串引來的思考？——命令模式