软命令接口的适用场合

看到有些朋友很喜欢用软命令的方式来提供接口, 什么是软命令, 其实就是一个接口,根据参数的不同,可以实现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模式就是为此而准备的，这里就不多说了。