命名模式的目標是將方法的調(diào)用,請求或者操作封裝到一個單獨的對象中,給我們酌情執(zhí)行同時參數(shù)化和傳遞方法調(diào)用的能力.另外,它使得我們能將對象從實現(xiàn)了行為的對象對這些行為的調(diào)用進行解耦,為我們帶來了換出具體的對象這一更深程度的整體靈活性。

具體類是對基于類的編程語言的最好解釋,并且同抽象類的理念聯(lián)系緊密.抽象類定義了一個接口,但并不需要提供對它的所有成員函數(shù)的實現(xiàn).它扮演著驅(qū)動其它類的基類角色.被驅(qū)動類實現(xiàn)了缺失的函數(shù)而被稱為具體類. 命令模式背后的一般理念是為我們提供了從任何執(zhí)行中的命令中分離出發(fā)出命令的責任,取而代之將這一責任委托給其它的對象。

實現(xiàn)明智簡單的命令對象,將一個行為和對象對調(diào)用這個行為的需求都綁定到了一起.它們始終都包含一個執(zhí)行操作(比如run()或者execute()).所有帶有相同接口的命令對象能夠被簡單地根據(jù)需要調(diào)換,這被認為是命令模式的更大的好處之一。

為了展示命令模式,我們創(chuàng)建一個簡單的汽車購買服務:

(function(){

  var CarManager = {

      // request information
      requestInfo: function( model, id ){
        return "The information for " + model + " with ID " + id + " is foobar";
      },

      // purchase the car
      buyVehicle: function( model, id ){
        return "You have successfully purchased Item " + id + ", a " + model;
      },

      // arrange a viewing
      arrangeViewing: function( model, id ){
        return "You have successfully booked a viewing of " + model + " ( " + id + " ) ";
      }

    };

})();

看一看上面的這段代碼,它也許是通過直接訪問對象來瑣碎的調(diào)用我們CarManager的方法。在技術(shù)上我們也許都會都會對這個沒有任何失誤達成諒解.它是完全有效的Javascript然而也會有情況不利的情況。

例如,想象如果CarManager的核心API會發(fā)生改變的這種情況.這可能需要所有直接訪問這些方法的對象也跟著被修改.這可以被看成是一種耦合,明顯違背了OOP方法學盡量實現(xiàn)松耦合的理念.取而代之,我們可以通過更深入的抽象這些API來解決這個問題。

現(xiàn)在讓我們來擴展我們的CarManager,以便我們這個命令模式的應用程序得到接下來的這種效果:接受任何可以在CarManager對象上面執(zhí)行的方法,傳送任何可以被使用到的數(shù)據(jù),如Car模型和ID。

這里是我們希望能夠?qū)崿F(xiàn)的樣子:

CarManager.execute( "buyVehicle", "Ford Escort", "453543" );

按照這種結(jié)構(gòu),我們現(xiàn)在應該像下面這樣,添加一個對于"CarManager.execute()"方法的定義：

CarManager.execute = function ( name ) {
    return CarManager[name] && CarManager[name].apply( CarManager, [].slice.call(arguments, 1) );
};

最終我們的調(diào)用如下所示:

CarManager.execute( "arrangeViewing", "Ferrari", "14523" );
CarManager.execute( "requestInfo", "Ford Mondeo", "54323" );
CarManager.execute( "requestInfo", "Ford Escort", "34232" );
CarManager.execute( "buyVehicle", "Ford Escort", "34232" );