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