[架構設計]反向（或者後向）插件系統設計

       反向（或者後向）插件系統與正向（或者前向）插件系統是一對概念相對的設計模式。正向插件系統是指系統架構的時候預先定義好一系列用於某種特定目的的函數族，而後經過共享庫的形式封裝不一樣的實現策略，已達到靈活配置的目的，正向插件系統的設計在於插件向主程序公開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