定義：将一(yī)個請求封裝成一(yī)個對象，從而讓你使用不同的請求把客戶端參數化，對請求排隊或者記錄請求日志(zhì)，可以提供命令的撤銷和恢複功能。
類型：行爲類模式
類圖：
命令模式的結構
顧名思義，命令模式就是對命令的封裝，首先來看一(yī)下(xià)命令模式類圖中(zhōng)的基本結構：
Command類：是一(yī)個抽象類，類中(zhōng)對需要執行的命令進行聲明，一(yī)般來說要對外(wài)公布一(yī)個execute方法用來執行命令。
ConcreteCommand類：Command類的實現類，對抽象類中(zhōng)聲明的方法進行實現。
Client類：最終的客戶端調用類。
以上三個類的作用應該是比較好理解的，下(xià)面我(wǒ)們重點說一(yī)下(xià)Invoker類和Recevier類。
Invoker類：調用者，負責調用命令。
Receiver類：接收者，負責接收命令并且執行命令。
所謂對命令的封裝，說白(bái)了，無非就是把一(yī)系列的操作寫到一(yī)個方法中(zhōng)，然後供客戶端調用就行了，反映到類圖上，隻需要一(yī)個ConcreteCommand類和Client類就可以完成對命令的封裝，即使再進一(yī)步，爲了增加靈活性，可以再增加一(yī)個Command類進行适當地抽象，這個調用者和接收者到底是什麽作用呢？
其實大(dà)家可以換一(yī)個角度去(qù)想：假如僅僅是簡單地把一(yī)些操作封裝起來作爲一(yī)條命令供别人調用，怎麽能稱爲一(yī)種模式呢？命令模式作爲一(yī)種行爲類模式，首先要做到低耦合，耦合度低了才能提高靈活性，而加入調用者和接收者兩個角色的目的也正是爲此。命令模式的通用代碼如下(xià)：
class Invoker {
private Command command;
public void setCommand(Command command) {
this.command = command;
}
public void action(){
this.command.execute();
}
}
abstract class Command {
public abstract void execute();
}
class ConcreteCommand extends Command {
private Receiver receiver;
public ConcreteCommand(Receiver receiver){
this.receiver = receiver;
}
public void execute() {
this.receiver.doSomething();
}
}
class Receiver {
public void doSomething(){
System.out.println("接受者-業務邏輯處理");
}
}
public class Client {
public static void main(String[] args){
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
//客戶端直接執行具體(tǐ)命令方式（此方式與類圖相符）
command.execute();
//客戶端通過調用者來執行命令
Invoker invoker = new Invoker();
invoker.setCommand(command);
invoker.action();
}
}通過代碼我(wǒ)們可以看到，當我(wǒ)們調用時，執行的時序首先是調用者類，然後是命令類，最後是接收者類。也就是說一(yī)條命令的執行被分(fēn)成了三步，它的耦合度要比把所有的操作都封裝到一(yī)個類中(zhōng)要低的多，而這也正是命令模式的精髓所在：把命令的調用者與執行者分(fēn)開(kāi)，使雙方不必關心對方是如何操作的。
命令模式的優缺點
首先，命令模式的封裝性很好：每個命令都被封裝起來，對于客戶端來說，需要什麽功能就去(qù)調用相應的命令，而無需知(zhī)道命令具體(tǐ)是怎麽執行的。比如有一(yī)組文件操作的命令：新建文件、複制文件、删除文件。如果把這三個操作都封裝成一(yī)個命令類，客戶端隻需要知(zhī)道有這三個命令類即可，至于命令類中(zhōng)封裝好的邏輯，客戶端則無需知(zhī)道。
其次，命令模式的擴展性很好，在命令模式中(zhōng)，在接收者類中(zhōng)一(yī)般會對操作進行最基本的封裝，命令類則通過對這些基本的操作進行二次封裝，當增加新命令的時候，對命令類的編寫一(yī)般不是從零開(kāi)始的，有大(dà)量的接收者類可供調用，也有大(dà)量的命令類可供調用，代碼的複用性很好。比如，文件的操作中(zhōng)，我(wǒ)們需要增加一(yī)個剪切文件的命令，則隻需要把複制文件和删除文件這兩個命令組合一(yī)下(xià)就行了，非常方便。
最後說一(yī)下(xià)命令模式的缺點，那就是命令如果很多，開(kāi)發起來就要頭疼了。特别是很多簡單的命令，實現起來就幾行代碼的事，而使用命令模式的話(huà)，不用管命令多簡單，都需要寫一(yī)個命令類來封裝。
命令模式的适用場景
對于大(dà)多數請求-響應模式的功能，比較适合使用命令模式，正如命令模式定義說的那樣，命令模式對實現記錄日志(zhì)、撤銷操作等功能比較方便。
總結
對于一(yī)個場合到底用不用模式，這對所有的開(kāi)發人員(yuán)來說都是一(yī)個很糾結的問題。有時候，因爲預見到需求上會發生(shēng)的某些變化，爲了系統的靈活性和可擴展性而使用了某種設計模式，但這個預見的需求偏偏沒有，相反，沒預見到的需求倒是來了不少，導緻在修改代碼的時候，使用的設計模式反而起了相反的作用，以至于整個項目組怨聲載道。這樣的例子，我(wǒ)相信每個程序設計者都遇到過。所以，基于敏捷開(kāi)發的原則，我(wǒ)們在設計程序的時候，如果按照目前的需求，不使用某種模式也能很好地解決，那麽我(wǒ)們就不要引入它，因爲要引入一(yī)種設計模式并不困難，我(wǒ)們大(dà)可以在真正需要用到的時候再對系統進行一(yī)下(xià)，引入這個設計模式。
拿命令模式來說吧，我(wǒ)們開(kāi)發中(zhōng)，請求-響應模式的功能非常常見，一(yī)般來說，我(wǒ)們會把對請求的響應操作封裝到一(yī)個方法中(zhōng)，這個封裝的方法可以稱之爲命令，但不是命令模式。到底要不要把這種設計上升到模式的高度就要另行考慮了，因爲，如果使用命令模式，就要引入調用者、接收者兩個角色，原本放(fàng)在一(yī)處的邏輯分(fēn)散到了三個類中(zhōng)，設計時，必須考慮這樣的代價是否值得。
