看到有些朋友很喜歡用軟命令的方式來提供接口, 什么是軟命令, 其實就是一個接口,根據(jù)參數(shù)的不同,可以實現(xiàn)N多的功能(我不知道"軟命令"這名詞是我原創(chuàng)還是現(xiàn)有的，我們暫時就這樣稱呼吧).
看看現(xiàn)實中有哪些產(chǎn)品已經(jīng)成功應(yīng)用了這種特性?
首先想到是的是windows窗口的消息處理函數(shù)，用C的方式是類似這樣：
LRESULT MessageProc(HWND hWnd, UINT nMsgType, WPARAM wParam, LPARAM lParam);
用C++實現(xiàn)是類似這樣
class CWindow
{
public:
LRESULT MessageHander(UINT nMsgType, WPARAM wParam, LPARAM lParam);
};
當然里面實現(xiàn)時會有一堆switch case.
接下來會想到COM里IDispatch接口的Invoke函數(shù)，外部無論調(diào)用對象的什么方法或?qū)傩?，都通過這個自動化接口。
再往廣義上想，DOS里的命令行，Windbg的操作命令等，其實都是"軟命令"。
再廣一點， 整個Web服務(wù)器就是一個"軟命令"入口，比如URL API，都是通過一個單獨的Http請求入口，可以實現(xiàn)各種各樣的任務(wù)。
我們對上面的例子進行抽象，就會發(fā)現(xiàn)他們的共性是對外接口固定，但是內(nèi)部功能確是可以擴充，很符合開放封閉這條設(shè)計原則。往設(shè)計模式上考慮， 其實就是單一入口的Facade模式。
這么方便的接口，那么是不是在我們平時的設(shè)計中應(yīng)該盡量使用呢? 我看未必。 如果按照這種設(shè)計，任何類都只要一個MethodCallRequest方法就好了，根據(jù)這個入口，我會根據(jù)你的命令類型，調(diào)用相應(yīng)的方法。如果你真的所有的類都這樣做了，等類層次一復(fù)雜，我看你的代碼就不用維護了。當然也有語言確實是這么做的，比如Objective-c, 它內(nèi)部對象的每個函數(shù)調(diào)用，都是通過查找對象的function table， 然后再調(diào)用對應(yīng)的function，但它的前提是語言本身提供這個特性。但是像C++這種靜態(tài)強類型的語言，讓對象的每個方法有明確的用途，讓編譯器幫你檢測對象是不是有相應(yīng)的方法，一來清晰，而來高效，何樂而不為？
那么究竟什么時候適用這種接口方式呢？
我的看法是只有當你的模塊是一個單獨的子系統(tǒng)，當對外提供功能時，才可以這么做。這里的子系統(tǒng)不一定要是一個很大的概念，比如一個窗口，一個COM對象都可以稱為簡單的子系統(tǒng)，但是它的前提要求是獨立，對外，并且最好你可以預(yù)見到以后它的功能會改變和擴充。
那么有沒有不用這種"軟命令"的接口方式，但是我也可以不斷擴充對象提供的方法呢？ 有的，設(shè)計模式里的Visitor模式就是為此而準備的，這里就不多說了。
posted on 2012-06-13 10:08
Richard Wei 閱讀(3384)
評論(5) 編輯 收藏 引用 所屬分類:
設(shè)計模式