# 命令模式 命名模式的目標是將方法的調用,請求或者操作封裝到一個單獨的對象中,給我們酌情執行同時參數化和傳遞方法調用的能力.另外,它使得我們能將對象從實現了行為的對象對這些行為的調用進行解耦,為我們帶來了換出具體的對象這一更深程度的整體靈活性。 具體類是對基于類的編程語言的最好解釋,并且同抽象類的理念聯系緊密.抽象類定義了一個接口,但并不需要提供對它的所有成員函數的實現.它扮演著驅動其它類的基類角色.被驅動類實現了缺失的函數而被稱為具體類. 命令模式背后的一般理念是為我們提供了從任何執行中的命令中分離出發出命令的責任,取而代之將這一責任委托給其它的對象。 實現明智簡單的命令對象,將一個行為和對象對調用這個行為的需求都綁定到了一起.它們始終都包含一個執行操作(比如run()或者execute()).所有帶有相同接口的命令對象能夠被簡單地根據需要調換,這被認為是命令模式的更大的好處之一。 為了展示命令模式,我們創建一個簡單的汽車購買服務: ~~~ (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 + " ) "; } }; })(); ~~~ 看一看上面的這段代碼,它也許是通過直接訪問對象來瑣碎的調用我們CarManager的方法。在技術上我們也許都會都會對這個沒有任何失誤達成諒解.它是完全有效的Javascript然而也會有情況不利的情況。 例如,想象如果CarManager的核心API會發生改變的這種情況.這可能需要所有直接訪問這些方法的對象也跟著被修改.這可以被看成是一種耦合,明顯違背了OOP方法學盡量實現松耦合的理念.取而代之,我們可以通過更深入的抽象這些API來解決這個問題。 現在讓我們來擴展我們的CarManager,以便我們這個命令模式的應用程序得到接下來的這種效果:接受任何可以在CarManager對象上面執行的方法,傳送任何可以被使用到的數據,如Car模型和ID。 這里是我們希望能夠實現的樣子: ~~~ CarManager.execute( "buyVehicle", "Ford Escort", "453543" ); ~~~ 按照這種結構,我們現在應該像下面這樣,添加一個對于"CarManager.execute()"方法的定義： ~~~ CarManager.execute = function ( name ) { return CarManager[name] && CarManager[name].apply( CarManager, [].slice.call(arguments, 1) ); }; ~~~ 最終我們的調用如下所示: ~~~ CarManager.execute( "arrangeViewing", "Ferrari", "14523" ); CarManager.execute( "requestInfo", "Ford Mondeo", "54323" ); CarManager.execute( "requestInfo", "Ford Escort", "34232" ); CarManager.execute( "buyVehicle", "Ford Escort", "34232" ); ~~~