软命令接口的适用场合

软命令接口的适用场合

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

在这种软命令下，只能给对象发送消息，对象可以采取种种方式响应消息，甚至可在对象外面响应消息，在外面截取消息，不让消息流进到之前的消息处理中。这样，就不会存在什么复杂类层次结构。这种方式，在下认为并不是“单一入口的Faced模式”，而是几乎包含了所有接口的变种桥接模式 
  

这个怎么说呢，Faced模式强调的是一个复杂系统对外有一个统一的入口； Bridge模式强调的是分层的概念，将抽象层和实现层分离，二层可以分别独立的变化。感觉上面的"软命令"方式，从对外暴露的接口的简单统一性来说比较符合Faced模式；但是从内部实现来说，你要理解成同一消息可以有多种处理方式，Bridge模式也可以。