軟命令介面的適用場合

萬個函式千個類發表於2013-02-28
看到有些朋友很喜歡用軟命令的方式來提供介面, 什麼是軟命令, 其實就是一個介面,根據引數的不同,可以實現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模式就是為此而準備的，這裡就不多說了。

相關文章