定義：

將一個請求封裝成一個對象，從而讓你使用不同的請求把客戶端參數化，對請求排隊或者記錄請求日志，可以提供命令的撤銷和恢復功能。

其實就是發送一個命令，叫接收者干具體事情，和間接調用不同的是，間接調用時直接調用接受者的方法，而這里只是用一個命令方法再次調用do,接受者就開始干；
優點：只要發送一個命令，就可以讓接受者執行很多方法；也可以讓多個接受者開始執行；

命令模式.png

角色

• Command類：是一個抽象類，類中對需要執行的命令進行聲明，一般來說要對外公布一個execute方法用來執行命令。

• ConcreteCommand類：Command類的實現類，對抽象類中聲明的方法進行實現。

• Invoker類：調用者，負責調用命令。

• Receiver類：接收者，負責接收命令并且執行命令。

• Client類：最終的客戶端調用類。

所謂對命令的封裝，說白了，無非就是把一系列的操作寫到一個方法中，然后供客戶端調用就行了，反映到類圖上，只需要一個ConcreteCommand類和Client類就可以完成對命令的封裝，即使再進一步，為了增加靈活性，可以再增加一個Command類進行適當地抽象，這個調用者和接收者到底是什么作用呢？
其實大家可以換一個角度去想：假如僅僅是簡單地把一些操作封裝起來作為一條命令供別人調用，怎么能稱為一種模式呢？命令模式作為一種行為類模式，首先要做到低耦合，耦合度低了才能提高靈活性，而加入調用者和接收者兩個角色的目的也正是為此。

實現代碼

抽象的Command命令類

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

具體命令實現類ConcreteCommand

class ConcreteCommand extends Command {  
    private Receiver receiver;  
    public ConcreteCommand(Receiver receiver){  
        this.receiver = receiver;  
    }  
    public void execute() {  
        this.receiver.doSomething();  
    }  
}  

接受者Receiver

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

調用者Invoker

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

Client

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();  
    }  
}  

通過代碼我們可以看到，當我們調用時，執行的時序首先是調用者類，然后是命令類，最后是接收者類。也就是說一條命令的執行被分成了三步，它的耦合度要比把所有的操作都封裝到一個類中要低的多，而這也正是命令模式的精髓所在：把命令的調用者與執行者分開，使雙方不必關心對方是如何操作的。
命令模式的優缺點
首先，命令模式的封裝性很好：每個命令都被封裝起來，對于客戶端來說，需要什么功能就去調用相應的命令，而無需知道命令具體是怎么執行的。比如有一組文件操作的命令：新建文件、復制文件、刪除文件。如果把這三個操作都封裝成一個命令類，客戶端只需要知道有這三個命令類即可，至于命令類中封裝好的邏輯，客戶端則無需知道。
其次，命令模式的擴展性很好，在命令模式中，在接收者類中一般會對操作進行最基本的封裝，命令類則通過對這些基本的操作進行二次封裝，當增加新命令的時候，對命令類的編寫一般不是從零開始的，有大量的接收者類可供調用，也有大量的命令類可供調用，代碼的復用性很好。比如，文件的操作中，我們需要增加一個剪切文件的命令，則只需要把復制文件和刪除文件這兩個命令組合一下就行了，非常方便。
最后說一下命令模式的缺點，那就是命令如果很多，開發起來就要頭疼了。特別是很多簡單的命令，實現起來就幾行代碼的事，而使用命令模式的話，不用管命令多簡單，都需要寫一個命令類來封裝。

命令模式的適用場景
對于大多數請求-響應模式的功能，比較適合使用命令模式，正如命令模式定義說的那樣，命令模式對實現記錄日志、撤銷操作等功能比較方便。

總結
對于一個場合到底用不用模式，這對所有的開發人員來說都是一個很糾結的問題。有時候，因為預見到需求上會發生的某些變化，為了系統的靈活性和可擴展性而使用了某種設計模式，但這個預見的需求偏偏沒有，相反，沒預見到的需求倒是來了不少，導致在修改代碼的時候，使用的設計模式反而起了相反的作用，以至于整個項目組怨聲載道。這樣的例子，我相信每個程序設計者都遇到過。所以，基于敏捷開發的原則，我們在設計程序的時候，如果按照目前的需求，不使用某種模式也能很好地解決，那么我們就不要引入它，因為要引入一種設計模式并不困難，我們大可以在真正需要用到的時候再對系統進行一下，引入這個設計模式。
拿命令模式來說吧，我們開發中，請求-響應模式的功能非常常見，一般來說，我們會把對請求的響應操作封裝到一個方法中，這個封裝的方法可以稱之為命令，但不是命令模式。到底要不要把這種設計上升到模式的高度就要另行考慮了，因為，如果使用命令模式，就要引入調用者、接收者兩個角色，原本放在一處的邏輯分散到了三個類中，設計時，必須考慮這樣的代價是否值得。