反向（或者后向）插件系统设计

反向（或者后向）插件系统与正向（或者前向）插件系统是一对概念相对的设计模式。正向插件系统是指系统架构的时候预先定义好一系列用于某种特定目的的函数族，然后通过共享库的形式封装不同的实现策略，已达到灵活配置的目的，正向插件系统的设计在于插件向主程序公开API；反向插件系统是指系统架构的时候并未想好应该区分哪些插件类型，但是为了主程序的扩展性，可以对主程序进行某种形式的API公开，这些公开的API可能不止一种目的，因而日后在对主程序的扩展时可选择性就更多。

还要说明的是，反向插件系统设计可能包含了前向插件系统的设计，因为只要是插件，就必不可少的被主程序加以某种条件制约：可能是创建形式的制约；可能是运行时的制约；也可能是为了区分不同插件类型而做的制约。

反向插件系统的实现方式有很多，如：

Windows的进程外COM就是一种反向插件系统的设计：主程序既能保留自己运行的独立性，同时还能公开自己的API供其他的开发目的使用；而相对的进程内COM只是一种正向插件设计：插件只能运行在主程序的进程空间内，同时它的设计目的主要的就是对外公开自己的能够实现一定目的的API接口。

另外一种常见的反向插件系统是编程语言的跨语言调用。如果读者熟悉Lua和C/C++之间的调用，应该能够明白——Lua状态机（也就是插件）运行在C/C++编写的主程序进程内，如果不同的Lua源码实现了特定的API函数族，然后供C/C++使用，这就是前向插件设计；而如果Lua需要使用C/C++提供的函数（API），这就满足了反向插件系统的概念：首先由C/C++注册一系列的接口函数，然后Lua状态机解释这些API给Lua调用。

还有一种跨语言的调用也很常见——JNI。JNI是Java程序和C/C++程序之间进行互相调用的技术规范。Java程序可以通过定义接口函数族，然后由C/C++程序实现；而C/C++程序也可以使用Java运行时提供的API调用Java程序。

话到现在，我是不清楚读者能否听得懂我在讲些什么。如果还是不懂，我希望通过下面的案例能够让您明白。

假设我们已经实现了一个图像预览的主程序，这个主程序能够实现放大、缩小、旋转、拍照等功能，并且这个主程序已经被发布了。忽然有一天，客户提出这样一个要求，他们手上有一台中控设备，这台设备可以通过串口和电脑相连，恰好这台设备可以发送三个不同的命令（或者更多），然后他们希望可以通过设备上的按键命令控制那个图像预览程序的放大、缩小和旋转。

我们可以分析一下，为了不让客户的特殊需求污染了原来程序的设计，只能设计成某种形式的插件系统，并且可以通过配置文件灵活的取消或者启用这个特殊的插件。

如果设计成前向插件系统，那么主程序必须实现插件约定的某种接口，如果使用C/C++实现的话可以使用回调函数或者虚类。一方面，如果插件需要主程序提供的API过多，将会让接口约定变得很长；另一方面，如果有另外更多用途的插件需要主程序提供各自不同的API，这个时候主程序的设计将陷入由插件主导的尴尬境地。如何解决上述（或许还有没有讲到的）问题呢？反向插件系统就是一种很好的选择。

首先，反向插件系统要求主程序在接口设计上处于主导地位，主程序公开了什么API，插件就只能使用什么API；其次，主程序可以通过归纳对需要公开的接口进行分类，避免上述问题导致的导出重复API的可能。

那么针对上述项目，该如何进行反向插件系统的设计呢？

首先，主程序需要提供某种形式的运行时机制，插件能够通过该机制获取主程序公开的函数、对象等。其次，主程序需要定义运行时机制的装载和卸载过程。最后，主程序可以规定一些用于特定插件的接口规范。

详细的代码实现可以参考这个项目：PluginRuntime