文章來源： http://blog.csdn.net/zhengzhb/article/details/7550895
定義： 將一個請求封裝成一個對象，從而讓你使用不同的請求把客戶端參數(shù)化，對請求排隊(duì)或者記錄請求日志，可以提供命令的撤銷和恢復(fù)功能。
類型： 行為類模式
類圖：
命令模式的結(jié)構(gòu)
顧名思義，命令模式就是對命令的封裝，首先來看一下命令模式類圖中的基本結(jié)構(gòu)：
- Command類： 是一個抽象類，類中對需要執(zhí)行的命令進(jìn)行聲明，一般來說要對外公布一個execute方法用來執(zhí)行命令。
- ConcreteCommand類： Command類的實(shí)現(xiàn)類，對抽象類中聲明的方法進(jìn)行實(shí)現(xiàn)。
- Client類： 最終的客戶端調(diào)用類。
以上三個類的作用應(yīng)該是比較好理解的，下面我們重點(diǎn)說一下Invoker類和Recevier類。
- Invoker類： 調(diào)用者，負(fù)責(zé)調(diào)用命令。
- Receiver類： 接收者，負(fù)責(zé)接收命令并且執(zhí)行命令。
所謂對命令的封裝，說白了，無非就是把一系列的操作寫到一個方法中，然后供客戶端調(diào)用就行了，反映到類圖上，只需要一個ConcreteCommand類和Client類就可以完成對命令的封裝，即使再進(jìn)一步，為了增加靈活性，可以再增加一個Command類進(jìn)行適當(dāng)?shù)爻橄螅@個調(diào)用者和接收者到底是什么作用呢？
其實(shí)大家可以換一個角度去想：假如僅僅是簡單地把一些操作封裝起來作為一條命令供別人調(diào)用，怎么能稱為一種模式呢？命令模式作為一種行為類模式，首先要做到低耦合，耦合度低了才能提高靈活性，而加入調(diào)用者和接收者兩個角色的目的也正是為此。命令模式的通用代碼如下：
- class Invoker{
- private Commandcommand;
- public void setCommand(Commandcommand){
- this .command=command;
- }
- public void action(){
- this .command.execute();
- }
- }
- abstract class Command{
- public abstract void execute();
- }
- class ConcreteCommand extends Command{
- private Receiverreceiver;
- public ConcreteCommand(Receiverreceiver){
- this .receiver=receiver;
- }
- public void execute(){
- this .receiver.doSomething();
- }
- }
- class Receiver{
- public void doSomething(){
- System.out.println( "接受者-業(yè)務(wù)邏輯處理" );
- }
- }
- public class Client{
- public static void main(String[]args){
- Receiverreceiver= new Receiver();
- Commandcommand= new ConcreteCommand(receiver);
- //客戶端直接執(zhí)行具體命令方式（此方式與類圖相符）
- command.execute();
- //客戶端通過調(diào)用者來執(zhí)行命令
- Invokerinvoker= new Invoker();
- invoker.setCommand(command);
- invoker.action();
- }
- }
通過代碼我們可以看到，當(dāng)我們調(diào)用時，執(zhí)行的時序首先是調(diào)用者類，然后是命令類，最后是接收者類。也就是說一條命令的執(zhí)行被分成了三步，它的耦合度要比把所有的操作都封裝到一個類中要低的多，而這也正是命令模式的精髓所在：把命令的調(diào)用者與執(zhí)行者分開，使雙方不必關(guān)心對方是如何操作的。
命令模式的優(yōu)缺點(diǎn)
首先，命令模式的封裝性很好：每個命令都被封裝起來，對于客戶端來說，需要什么功能就去調(diào)用相應(yīng)的命令，而無需知道命令具體是怎么執(zhí)行的。比如有一組文件操作的命令：新建文件、復(fù)制文件、刪除文件。如果把這三個操作都封裝成一個命令類，客戶端只需要知道有這三個命令類即可，至于命令類中封裝好的邏輯，客戶端則無需知道。
其次，命令模式的擴(kuò)展性很好，在命令模式中，在接收者類中一般會對操作進(jìn)行最基本的封裝，命令類則通過對這些基本的操作進(jìn)行二次封裝，當(dāng)增加新命令的時候，對命令類的編寫一般不是從零開始的，有大量的接收者類可供調(diào)用，也有大量的命令類可供調(diào)用，代碼的復(fù)用性很好。比如，文件的操作中，我們需要增加一個剪切文件的命令，則只需要把復(fù)制文件和刪除文件這兩個命令組合一下就行了，非常方便。
最后說一下命令模式的缺點(diǎn)，那就是命令如果很多，開發(fā)起來就要頭疼了。特別是很多簡單的命令，實(shí)現(xiàn)起來就幾行代碼的事，而使用命令模式的話，不用管命令多簡單，都需要寫一個命令類來封裝。
命令模式的適用場景
對于大多數(shù)請求-響應(yīng)模式的功能，比較適合使用命令模式，正如命令模式定義說的那樣，命令模式對實(shí)現(xiàn)記錄日志、撤銷操作等功能比較方便。
總結(jié)
對于一個場合到底用不用模式，這對所有的開發(fā)人員來說都是一個很糾結(jié)的問題。有時候，因?yàn)轭A(yù)見到需求上會發(fā)生的某些變化，為了系統(tǒng)的靈活性和可擴(kuò)展性而使用了某種設(shè)計(jì)模式，但這個預(yù)見的需求偏偏沒有，相反，沒預(yù)見到的需求倒是來了不少，導(dǎo)致在修改代碼的時候，使用的設(shè)計(jì)模式反而起了相反的作用，以至于整個項(xiàng)目組怨聲載道。這樣的例子，我相信每個程序設(shè)計(jì)者都遇到過。所以，基于敏捷開發(fā)的原則，我們在設(shè)計(jì)程序的時候，如果按照目前的需求，不使用某種模式也能很好地解決，那么我們就不要引入它，因?yàn)橐胍环N設(shè)計(jì)模式并不困難，我們大可以在真正需要用到的時候再對系統(tǒng)進(jìn)行一下，引入這個設(shè)計(jì)模式。
拿命令模式來說吧，我們開發(fā)中，請求-響應(yīng)模式的功能非常常見，一般來說，我們會把對請求的響應(yīng)操作封裝到一個方法中，這個封裝的方法可以稱之為命令，但不是命令模式。到底要不要把這種設(shè)計(jì)上升到模式的高度就要另行考慮了，因?yàn)椋绻褂妹钅Ｊ剑鸵胝{(diào)用者、接收者兩個角色，原本放在一處的邏輯分散到了三個類中，設(shè)計(jì)時，必須考慮這樣的代價是否值得。
文章來源： http://blog.csdn.net/zhengzhb/article/details/7550895
定義： 將一個請求封裝成一個對象，從而讓你使用不同的請求把客戶端參數(shù)化，對請求排隊(duì)或者記錄請求日志，可以提供命令的撤銷和恢復(fù)功能。
類型： 行為類模式
類圖：
命令模式的結(jié)構(gòu)
顧名思義，命令模式就是對命令的封裝，首先來看一下命令模式類圖中的基本結(jié)構(gòu)：
- Command類： 是一個抽象類，類中對需要執(zhí)行的命令進(jìn)行聲明，一般來說要對外公布一個execute方法用來執(zhí)行命令。
- ConcreteCommand類： Command類的實(shí)現(xiàn)類，對抽象類中聲明的方法進(jìn)行實(shí)現(xiàn)。
- Client類： 最終的客戶端調(diào)用類。
以上三個類的作用應(yīng)該是比較好理解的，下面我們重點(diǎn)說一下Invoker類和Recevier類。
- Invoker類： 調(diào)用者，負(fù)責(zé)調(diào)用命令。
- Receiver類： 接收者，負(fù)責(zé)接收命令并且執(zhí)行命令。
所謂對命令的封裝，說白了，無非就是把一系列的操作寫到一個方法中，然后供客戶端調(diào)用就行了，反映到類圖上，只需要一個ConcreteCommand類和Client類就可以完成對命令的封裝，即使再進(jìn)一步，為了增加靈活性，可以再增加一個Command類進(jìn)行適當(dāng)?shù)爻橄螅@個調(diào)用者和接收者到底是什么作用呢？
其實(shí)大家可以換一個角度去想：假如僅僅是簡單地把一些操作封裝起來作為一條命令供別人調(diào)用，怎么能稱為一種模式呢？命令模式作為一種行為類模式，首先要做到低耦合，耦合度低了才能提高靈活性，而加入調(diào)用者和接收者兩個角色的目的也正是為此。命令模式的通用代碼如下：
- class Invoker{
- private Commandcommand;
- public void setCommand(Commandcommand){
- this .command=command;
- }
- public void action(){
- this .command.execute();
- }
- }
- abstract class Command{
- public abstract void execute();
- }
- class ConcreteCommand extends Command{
- private Receiverreceiver;
- public ConcreteCommand(Receiverreceiver){
- this .receiver=receiver;
- }
- public void execute(){
- this .receiver.doSomething();
- }
- }
- class Receiver{
- public void doSomething(){
- System.out.println( "接受者-業(yè)務(wù)邏輯處理" );
- }
- }
- public class Client{
- public static void main(String[]args){
- Receiverreceiver= new Receiver();
- Commandcommand= new ConcreteCommand(receiver);
- //客戶端直接執(zhí)行具體命令方式（此方式與類圖相符）
- command.execute();
- //客戶端通過調(diào)用者來執(zhí)行命令
- Invokerinvoker= new Invoker();
- invoker.setCommand(command);
- invoker.action();
- }
- }
通過代碼我們可以看到，當(dāng)我們調(diào)用時，執(zhí)行的時序首先是調(diào)用者類，然后是命令類，最后是接收者類。也就是說一條命令的執(zhí)行被分成了三步，它的耦合度要比把所有的操作都封裝到一個類中要低的多，而這也正是命令模式的精髓所在：把命令的調(diào)用者與執(zhí)行者分開，使雙方不必關(guān)心對方是如何操作的。
命令模式的優(yōu)缺點(diǎn)
首先，命令模式的封裝性很好：每個命令都被封裝起來，對于客戶端來說，需要什么功能就去調(diào)用相應(yīng)的命令，而無需知道命令具體是怎么執(zhí)行的。比如有一組文件操作的命令：新建文件、復(fù)制文件、刪除文件。如果把這三個操作都封裝成一個命令類，客戶端只需要知道有這三個命令類即可，至于命令類中封裝好的邏輯，客戶端則無需知道。
其次，命令模式的擴(kuò)展性很好，在命令模式中，在接收者類中一般會對操作進(jìn)行最基本的封裝，命令類則通過對這些基本的操作進(jìn)行二次封裝，當(dāng)增加新命令的時候，對命令類的編寫一般不是從零開始的，有大量的接收者類可供調(diào)用，也有大量的命令類可供調(diào)用，代碼的復(fù)用性很好。比如，文件的操作中，我們需要增加一個剪切文件的命令，則只需要把復(fù)制文件和刪除文件這兩個命令組合一下就行了，非常方便。
最后說一下命令模式的缺點(diǎn)，那就是命令如果很多，開發(fā)起來就要頭疼了。特別是很多簡單的命令，實(shí)現(xiàn)起來就幾行代碼的事，而使用命令模式的話，不用管命令多簡單，都需要寫一個命令類來封裝。
命令模式的適用場景
對于大多數(shù)請求-響應(yīng)模式的功能，比較適合使用命令模式，正如命令模式定義說的那樣，命令模式對實(shí)現(xiàn)記錄日志、撤銷操作等功能比較方便。
總結(jié)
對于一個場合到底用不用模式，這對所有的開發(fā)人員來說都是一個很糾結(jié)的問題。有時候，因?yàn)轭A(yù)見到需求上會發(fā)生的某些變化，為了系統(tǒng)的靈活性和可擴(kuò)展性而使用了某種設(shè)計(jì)模式，但這個預(yù)見的需求偏偏沒有，相反，沒預(yù)見到的需求倒是來了不少，導(dǎo)致在修改代碼的時候，使用的設(shè)計(jì)模式反而起了相反的作用，以至于整個項(xiàng)目組怨聲載道。這樣的例子，我相信每個程序設(shè)計(jì)者都遇到過。所以，基于敏捷開發(fā)的原則，我們在設(shè)計(jì)程序的時候，如果按照目前的需求，不使用某種模式也能很好地解決，那么我們就不要引入它，因?yàn)橐胍环N設(shè)計(jì)模式并不困難，我們大可以在真正需要用到的時候再對系統(tǒng)進(jìn)行一下，引入這個設(shè)計(jì)模式。
拿命令模式來說吧，我們開發(fā)中，請求-響應(yīng)模式的功能非常常見，一般來說，我們會把對請求的響應(yīng)操作封裝到一個方法中，這個封裝的方法可以稱之為命令，但不是命令模式。到底要不要把這種設(shè)計(jì)上升到模式的高度就要另行考慮了，因?yàn)椋绻褂妹钅Ｊ剑鸵胝{(diào)用者、接收者兩個角色，原本放在一處的邏輯分散到了三個類中，設(shè)計(jì)時，必須考慮這樣的代價是否值得。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長非常感激您！手機(jī)微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
