定義：將一個(gè)請(qǐng)求封裝成一個(gè)對(duì)象，從而讓你使用不同的請(qǐng)求把客戶端參數(shù)化，對(duì)請(qǐng)求排隊(duì)或者記錄請(qǐng)求日志，可以提供命令的撤銷和恢復(fù)功能。
類型：行為類模式
類圖：

命令模式的結(jié)構(gòu)
        顧名思義，命令模式就是對(duì)命令的封裝，首先來看一下命令模式類圖中的基本結(jié)構(gòu)：
Command類：是一個(gè)抽象類，類中對(duì)需要執(zhí)行的命令進(jìn)行聲明，一般來說要對(duì)外公布一個(gè)execute方法用來執(zhí)行命令。
ConcreteCommand類：Command類的實(shí)現(xiàn)類，對(duì)抽象類中聲明的方法進(jìn)行實(shí)現(xiàn)。
Client類：最終的客戶端調(diào)用類。
        以上三個(gè)類的作用應(yīng)該是比較好理解的，下面我們重點(diǎn)說一下Invoker類和Recevier類。
Invoker類：調(diào)用者，負(fù)責(zé)調(diào)用命令。
Receiver類：接收者，負(fù)責(zé)接收命令并且執(zhí)行命令。
        所謂對(duì)命令的封裝，說白了，無(wú)非就是把一系列的操作寫到一個(gè)方法中，然后供客戶端調(diào)用就行了，反映到類圖上，只需要一個(gè)ConcreteCommand類和Client類就可以完成對(duì)命令的封裝，即使再進(jìn)一步，為了增加靈活性，可以再增加一個(gè)Command類進(jìn)行適當(dāng)?shù)爻橄?，這個(gè)調(diào)用者和接收者到底是什么作用呢？
        其實(shí)大家可以換一個(gè)角度去想：假如僅僅是簡(jiǎn)單地把一些操作封裝起來作為一條命令供別人調(diào)用，怎么能稱為一種模式呢？命令模式作為一種行為類模式，首先要做到低耦合，耦合度低了才能提高靈活性，而加入調(diào)用者和接收者兩個(gè)角色的目的也正是為此。
例子:
模擬對(duì)電視機(jī)的操作有開機(jī)、關(guān)機(jī)、換臺(tái)命令。代碼如下

//執(zhí)行命令的接口 
public interface Command { 
　　void execute(); 
} 

//命令接收者Receiver 
public class Tv { 
　　public int currentChannel = 0; 
 
　　public void turnOn() { 
　　  System.out.println("The televisino is on."); 
　　} 
 
　　public void turnOff() { 
　　  System.out.println("The television is off."); 
　　} 
 
　　public void changeChannel(int channel) { 
　　  this.currentChannel = channel; 
　　  System.out.println("Now TV channel is " + channel); 
　　} 
} 

//開機(jī)命令ConcreteCommand 
public class CommandOn implements Command { 
　　private Tv myTv; 
 
　　public CommandOn(Tv tv) { 
　　  myTv = tv; 
　　} 
 
　　public void execute() { 
　　  myTv.turnOn(); 
　　} 
} 

//關(guān)機(jī)命令ConcreteCommand 
public class CommandOff implements Command { 
　　private Tv myTv; 
 
　　public CommandOff(Tv tv) { 
　　  myTv = tv; 
　　} 
 
　　public void execute() { 
　　  myTv.turnOff(); 
　　} 
} 

//頻道切換命令ConcreteCommand 
public class CommandChange implements Command { 
　　private Tv myTv; 
 
　　private int channel; 
 
　　public CommandChange(Tv tv, int channel) { 
　　  myTv = tv; 
 　　 this.channel = channel; 
　　} 
 
　　public void execute() { 
　　  myTv.changeChannel(channel); 
　　} 
} 

//可以看作是遙控器Invoker 
public class Control { 
　　private Command onCommand, offCommand, changeChannel; 
 
　　public Control(Command on, Command off, Command channel) { 
 　　 onCommand = on; 
 　　 offCommand = off; 
　　  changeChannel = channel; 
　　} 
 
　　public void turnOn() { 
　　  onCommand.execute(); 
　　} 
 
　　public void turnOff() { 
　　  offCommand.execute(); 
　　} 
 
　　public void changeChannel() { 
 　　 changeChannel.execute(); 
　　} 
} 

//測(cè)試類Client 
public class Client { 
　　public static void main(String[] args) { 
 　　 // 命令接收者Receiver 
 　　 Tv myTv = new Tv(); 
 　　 // 開機(jī)命令ConcreteCommond 
 　　 CommandOn on = new CommandOn(myTv); 
 　　 // 關(guān)機(jī)命令ConcreteCommond 
 　　 CommandOff off = new CommandOff(myTv); 
 　　 // 頻道切換命令ConcreteCommond 
 　　 CommandChange channel = new CommandChange(myTv, 2); 
 　　 // 命令控制對(duì)象Invoker 
　　  Control control = new Control(on, off, channel); 
 
 　　 // 開機(jī) 
 　　 control.turnOn(); 
 　　 // 切換頻道 
 　　 control.changeChannel(); 
 　　 // 關(guān)機(jī) 
 　　 control.turnOff(); 
　　} 
} 

執(zhí)行結(jié)果

The televisino is on. 
Now TV channel is 2 
The television is off. 

命令模式的優(yōu)缺點(diǎn)
        首先，命令模式的封裝性很好：每個(gè)命令都被封裝起來，對(duì)于客戶端來說，需要什么功能就去調(diào)用相應(yīng)的命令，而無(wú)需知道命令具體是怎么執(zhí)行的。比如有一組文件操作的命令：新建文件、復(fù)制文件、刪除文件。如果把這三個(gè)操作都封裝成一個(gè)命令類，客戶端只需要知道有這三個(gè)命令類即可，至于命令類中封裝好的邏輯，客戶端則無(wú)需知道。
        其次，命令模式的擴(kuò)展性很好，在命令模式中，在接收者類中一般會(huì)對(duì)操作進(jìn)行最基本的封裝，命令類則通過對(duì)這些基本的操作進(jìn)行二次封裝，當(dāng)增加新命令的時(shí)候，對(duì)命令類的編寫一般不是從零開始的，有大量的接收者類可供調(diào)用，也有大量的命令類可供調(diào)用，代碼的復(fù)用性很好。比如，文件的操作中，我們需要增加一個(gè)剪切文件的命令，則只需要把復(fù)制文件和刪除文件這兩個(gè)命令組合一下就行了，非常方便。
        最后說一下命令模式的缺點(diǎn)，那就是命令如果很多，開發(fā)起來就要頭疼了。特別是很多簡(jiǎn)單的命令，實(shí)現(xiàn)起來就幾行代碼的事，而使用命令模式的話，不用管命令多簡(jiǎn)單，都需要寫一個(gè)命令類來封裝。
 
命令模式的適用場(chǎng)景
       對(duì)于大多數(shù)請(qǐng)求-響應(yīng)模式的功能，比較適合使用命令模式，正如命令模式定義說的那樣，命令模式對(duì)實(shí)現(xiàn)記錄日志、撤銷操作等功能比較方便。
 
 總結(jié)
       對(duì)于一個(gè)場(chǎng)合到底用不用模式，這對(duì)所有的開發(fā)人員來說都是一個(gè)很糾結(jié)的問題。有時(shí)候，因?yàn)轭A(yù)見到需求上會(huì)發(fā)生的某些變化，為了系統(tǒng)的靈活性和可擴(kuò)展性而使用了某種設(shè)計(jì)模式，但這個(gè)預(yù)見的需求偏偏沒有，相反，沒預(yù)見到的需求倒是來了不少，導(dǎo)致在修改代碼的時(shí)候，使用的設(shè)計(jì)模式反而起了相反的作用，以至于整個(gè)項(xiàng)目組怨聲載道。這樣的例子，我相信每個(gè)程序設(shè)計(jì)者都遇到過。所以，基于敏捷開發(fā)的原則，我們?cè)谠O(shè)計(jì)程序的時(shí)候，如果按照目前的需求，不使用某種模式也能很好地解決，那么我們就不要引入它，因?yàn)橐胍环N設(shè)計(jì)模式并不困難，我們大可以在真正需要用到的時(shí)候再對(duì)系統(tǒng)進(jìn)行一下，引入這個(gè)設(shè)計(jì)模式。
       拿命令模式來說吧，我們開發(fā)中，請(qǐng)求-響應(yīng)模式的功能非常常見，一般來說，我們會(huì)把對(duì)請(qǐng)求的響應(yīng)操作封裝到一個(gè)方法中，這個(gè)封裝的方法可以稱之為命令，但不是命令模式。到底要不要把這種設(shè)計(jì)上升到模式的高度就要另行考慮了，因?yàn)?，如果使用命令模式，就要引入調(diào)用者、接收者兩個(gè)角色，原本放在一處的邏輯分散到了三個(gè)類中，設(shè)計(jì)時(shí)，必須考慮這樣的代價(jià)是否值得。

最新評(píng)論