?

　　在Gof的設計模式中，有一個模式引起的爭議比較大，有很多人甚至認為這個模式應該排除在OO模式之外，原因在于它不具有OO的特性。不管怎么說，這個引起爭議的模式還是非常特別的，只要我們靜下心來分析一下，不難發現它的迷人之處。這個模式就是Command模式。

　　一、基本的Command模式

　　最簡單的Command模式中，包含一個ICommand接口，接口只有一個方法Execute。不同的Command對象實現這個接口，客戶端程序通過接口訪問Execute方法的不同實現。

?

　　好像也沒什么，這個模式太簡單了，幾分鐘就能學會。

　　模式本身是簡單的，但模式中包含的思想就不簡單了。有人認為Command模式不夠OO的主要原因就是它用OO的思想封裝一個方法，將方法當作對象來使用。OO的思想中，所有的名詞都是對象，比如說人;對象有自己的屬性，比如說身高、體重;對象有自己的方法，比如說人會跑，所以有一個Run()的方法。對象、屬性、方法是面向對象的幾大基本特征。那這個Command模式在搞什么鬼——它居然將方法當作對象!太不可理解了，世界上根本就不會有Run這個對象。

　　Command模式的思想就是模糊了方法與對象的界限。上面說的場景其實可以用下面的方式來實現。

?

　　其中函數FunctionA、FunctionB、FunctionC分別對應到對象CommandA、CommandB、CommandC。不過采用Command模式比這種方法要更加靈活可變。

　　二、靜態分派與動態分派

　　分派(Dispatch)可以說是一種定位。不管我們采用什么語言編寫程序，在現在的計算機體系結構下，代碼最終都會變成函數調用。從代碼到具體的函數調用這個過程就是分派。

　　比如說，在圖1中的Client通過ICommand接口調用具體的Command對象Execute方法。這個過程就是一個分派。不過這個分派是在程序運行時才能確定下來，編譯的時候不知道Client將會調用A、B、C那個對象的方法，只有在運行時創建了對象后才知道。

　　在圖2中的Client直接調用FunctionA、FunctionB、FunctionC。這個過程也是一個分派。這個分派是編譯器就可以明確下來。

　　從上面的描述來看，分派有兩種情況：如果分派過程在編譯時就可以確定下來，就叫做靜態分派，或者叫早綁定;如果分派過程需要在運行時才能確定下來，就叫做動態分派，或者叫做晚綁定。

　　在C++、Java、C#、Delphi等語言中overload是靜態的分派，而override是動態的分派。

　　上面介紹的Command模式其實是利用override的特性將靜態的分派轉為了動態的分派，從而帶來更大的靈活性。

?

　　三、讓靜態語言“動”起來

　　很多設計模式都是因為語言的限制而產生出擴充語言表現力的方法。設計模式會向兩個方面轉化：一方面轉成語言層面，有些設計模式就可能直接成為語言的特性，比如說迭代器模式就是如此;另一方面轉化成架構層面，變成架構設計的基本框架，比如說Facade和Adapter模式。

　　這篇文章中的Command模式目的也是擴充語言的表現力，實現函數調用的動態分派，這樣運用設計模式可以讓我們使用的語言帶有動態語言的一部分特性。本來動態語言中的函數調用就遠比常規語言要靈活得多。

　　在Gof的設計模式中，還有一個模式的關鍵也在于“分派”，就是Visitor模式，這要比Command模式復雜一些了。大家可以自己看看。等以后有時間我也會寫一篇關于Visitor的文章。

　　動態語言的本質就是“晚綁定”，和這里的“動態分派”有著莫大的關聯。我們可以通過設計模式讓靜態語言動起來，對于原本就動態的語言，有些設計模式可能就沒有意義。

　　這里分析Command模式僅僅介紹了最基本的情況，對于一些復雜的變化也并不是動態語言就可以完全取代的。

　　四、不能“精通”的語言

　　精通不管對于什么來說都是非常困難的。“精”是指掌握語言本身的特征，能對語言靈活、精確地使用，“通”指的就是觸類旁通，舉一反三。

　　最開始學習編程的時候我們去學C++、Java、C#，這個時候只能學到“精”。等到幾年之后，自認為夠“精”了，然后去學設計模式，去學企業架構。這是一般人正常的學法。但是這樣學卻不能“精通”語言。就像上面說的，設計模式又很多會影響到語言，架構模式同樣會從語言中的到靈感。

　　僅僅學習語言是不可能精通的，只有學習分析、設計后再和最基本的相互印證才能逐漸領悟到語言的真諦，達到“精通”吧。