23種設計模式（10）：命令模式

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

類型：行爲類模式

類圖：

命令模式的結構

顧名思義，命令模式就是對命令的封裝，首先來看一下命令模式類圖中的基本結構：

• Command類：是一個抽象類，類中對須要執行的命令進行聲明，通常來講要對外公佈一個execute方法用來執行命令。
• ConcreteCommand類：Command類的實現類，對抽象類中聲明的方法進行實現。
• Client類：最終的客戶端調用類。

以上三個類的做用應該是比較好理解的，下面咱們重點說一下Invoker類和Recevier類。

• Invoker類：調用者，負責調用命令。
• Receiver類：接收者，負責接收命令而且執行命令。

所謂對命令的封裝，說白了，無非就是把一系列的操做寫到一個方法中，而後供客戶端調用就好了，反映到類圖上，只須要一個ConcreteCommand類和Client類就能夠完成對命令的封裝，即便再進一步，爲了增長靈活性，能夠再增長一個Command類進行適當地抽象，這個調用者和接收者究竟是什麼做用呢？

其實你們能夠換一個角度去想：假如僅僅是簡單地把一些操做封裝起來做爲一條命令供別人調用，怎麼能稱爲一種模式呢？命令模式做爲一種行爲類模式，首先要作到低耦合，耦合度低了才能提升靈活性，而加入調用者和接收者兩個角色的目的也正是爲此。命令模式的通用代碼以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

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 ) ;          //客戶端直接執行具體命令方式（此方式與類圖相符）          command . execute ( ) ;            //客戶端經過調用者來執行命令          Invoker invoker = new Invoker ( ) ;          invoker . setCommand ( command ) ;          invoker . action ( ) ;      } }

 

經過代碼咱們能夠看到，當咱們調用時，執行的時序首先是調用者類，而後是命令類，最後是接收者類。也就是說一條命令的執行被分紅了三步，它的耦合度要比把全部的操做都封裝到一個類中要低的多，而這也正是命令模式的精髓所在：把命令的調用者與執行者分開，使雙方沒必要關心對方是如何操做的。

 

命令模式的優缺點

首先，命令模式的封裝性很好：每一個命令都被封裝起來，對於客戶端來講，須要什麼功能就去調用相應的命令，而無需知道命令具體是怎麼執行的。好比有一組文件操做的命令：新建文件、複製文件、刪除文件。若是把這三個操做都封裝成一個命令類，客戶端只須要知道有這三個命令類便可，至於命令類中封裝好的邏輯，客戶端則無需知道。

其次，命令模式的擴展性很好，在命令模式中，在接收者類中通常會對操做進行最基本的封裝，命令類則經過對這些基本的操做進行二次封裝，當增長新命令的時候，對命令類的編寫通常不是從零開始的，有大量的接收者類可供調用，也有大量的命令類可供調用，代碼的複用性很好。好比，文件的操做中，咱們須要增長一個剪切文件的命令，則只須要把複製文件和刪除文件這兩個命令組合一下就好了，很是方便。

最後說一下命令模式的缺點，那就是命令若是不少，開發起來就要頭疼了。特別是不少簡單的命令，實現起來就幾行代碼的事，而使用命令模式的話，不用管命令多簡單，都須要寫一個命令類來封裝。

 

命令模式的適用場景

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

 

 總結

對於一個場合到底用不用模式，這對全部的開發人員來講都是一個很糾結的問題。有時候，由於預見到需求上會發生的某些變化，爲了系統的靈活性和可擴展性而使用了某種設計模式，但這個預見的需求恰恰沒有，相反，沒預見到的需求卻是來了很多，致使在修改代碼的時候，使用的設計模式反而起了相反的做用，以致於整個項目組怨聲載道。這樣的例子，我相信每一個程序設計者都遇到過。因此，基於敏捷開發的原則，咱們在設計程序的時候，若是按照目前的需求，不使用某種模式也能很好地解決，那麼咱們就不要引入它，由於要引入一種設計模式並不困難，咱們大能夠在真正須要用到的時候再對系統進行一下，引入這個設計模式。

拿命令模式來講吧，咱們開發中，請求-響應模式的功能很是常見，通常來講，咱們會把對請求的響應操做封裝到一個方法中，這個封裝的方法能夠稱之爲命令，但不是命令模式。到底要不要把這種設計上升到模式的高度就要另行考慮了，由於，若是使用命令模式，就要引入調用者、接收者兩個角色，本來放在一處的邏輯分散到了三個類中，設計時，必須考慮這樣的代價是否值得。