[架构设计]反向（或者后向）插件系统设计

       反向（或者后向）插件系统与正向（或者前向）插件系统是一对概念相对的设计模式。正向插件系统是指系统架构的时候预先定义好一系列用于某种特定目的的函数族，而后经过共享库的形式封装不一样的实现策略，已达到灵活配置的目的，正向插件系统的设计在于插件向主程序公开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