http://www.yuanma.org/data/2007/0807/article_2796.htm
本文討論一種簡單卻有效的插件體系結(jié)構(gòu)，它使用C++,動態(tài)鏈接庫，基于面向?qū)ο缶幊痰乃枷?br><BR>首先來看一下使用插件機制能給我們帶來哪些方面的好處，從而在適當時候合理的選擇使用
。<BR>1，&nbsp;<SPAN style="COLOR: #0000ff">增強代碼的透明度與一致性</SPAN>
：因為插件通常會封裝第三方類庫或是其他人編寫的代碼，需要清晰地定義出接口，用清晰一致的接口來面對所有事情。
你的代碼也不會被轉(zhuǎn)換程序或是庫的特殊定制需求弄得亂七糟。
改善工程的模塊化</SPAN>：你的代碼被清析地分成多個獨立的模塊，可以把它們安置在子工程中的文件組中。
這種解耦處理使得創(chuàng)建出的組件更加容易重用
更短的編譯時間</SPAN>：如果僅僅是為了解釋某些類的聲明，而這些類內(nèi)部使用了外部庫，
編譯器不再需要解析外部庫的頭文件了，因為具體實現(xiàn)是以私有的形式完成。
更換與增加組件</SPAN>：假如你需要向用戶發(fā)布補丁，那么更新單獨的插件而不是替代每一個安裝了的文件更為有效。
當使用新的渲染器或是新的單元類型來擴展你的游戲時，能過向引擎提供一組插件，可以很容易的實現(xiàn)。
在關閉源代碼的工程中使用GPL代碼</SPAN>：一般，假如你使用了GPL發(fā)布的代碼，那么你也需要開放你的源代碼。
然而，如果把GPL組件封裝在插件中，你就不必發(fā)布插件的源碼。
介紹<BR></SPAN>先簡單解釋一下什么是插件系統(tǒng)以及它如何工作：在普通的程序中，假如你需要代碼執(zhí)行一項特殊的任務，
你有兩種選擇：要么你自己編寫，要么你尋找一個已經(jīng)存在的滿足你需要的庫。現(xiàn)在，你的要求變了，那你只好重寫代碼或是尋找另一個不同的庫。
無論是哪種方式，都會導致你框架代碼中的那些依賴外部庫的代碼重寫。<BR>現(xiàn)在，我們可以有另外一種選擇：在插件系統(tǒng)中，
工程中的任何組件不再束縛于一種特定的實現(xiàn)（像渲染器既可以基于OpenGL,也可以選擇Direct3D）,它們會從框架代碼中剝離出來，
通過特定的方法被放入動態(tài)鏈接庫之中。<BR>所謂的特定方法包括在框架代碼中創(chuàng)建接口，這些接口使得框架與動態(tài)庫解耦。
插件提供接口的實現(xiàn)。我們把插件與普通的動態(tài)鏈接庫區(qū)分開來是因為它們的加載方式不同：程序不會直接鏈接插件，
而可能是在某些目錄下查找，如果發(fā)現(xiàn)便進行加載。所有插件都可以使用一種共同的方法與應用進行聯(lián)結(jié)。
常見的錯誤<BR></SPAN>一些程序員，當進行插件系統(tǒng)的設計時，可能會給每一個作為插件使用的動態(tài)庫添加一個如下函數(shù)類似的函數(shù)：
PluginClass *createInstance(const char*);
然后它們讓插件去提供一些類的實現(xiàn)。引擎用期望的對象名對加載的插件逐個進行查詢，
直到某個插件返回，這是典型的設計模式中“職責鏈”模式的做法。一些更聰明的程序員會做出新的設計，使插件在引擎中注冊自己，
或是用定制的實現(xiàn)替代引擎內(nèi)部缺省實現(xiàn)：
Void dllStartPlugin(PluginManager &amp;pm);
Void dllStopPlugin(PluginManager &amp;pm);
第一種設計的主要問題是：插件工廠創(chuàng)建的對象需要使用reinterpret_cast
;來進行轉(zhuǎn)換。通常，插件從共同基類（這里指PluginClass）派生，會引用一些不安全的感覺。實際上，這樣做也是沒意義的，
插件應該“默默”地響應輸入設備的請求，然后提交結(jié)果給輸出設備。<BR>在這種結(jié)構(gòu)下，為了提供相同接口的多個不同實現(xiàn)，需要的工作變得異常復雜，
如果插件可以用不同名字注冊自己（如Direct3DRenderer and OpenGLRenderer）,但是引擎不知道哪個具體實現(xiàn)對用戶的選擇是有效的。
假如把所有可能的實現(xiàn)列表硬編碼到程序中，那么使用插件結(jié)構(gòu)的目的也沒有意義了。<BR>假如插件系統(tǒng)通過一個框架或是庫(如游戲引擎) 實現(xiàn)，
架構(gòu)師也肯定會把功能暴露給應用程序使用。這樣，會帶來一些問題像如何在應用程序中使用插件，插件作者如何引擎的頭文件等，
這包含了潛在的三者之間版本沖突的可能性。<BR><SPAN style="COLOR: #0000ff">單獨的工廠</SPAN><BR>接口，是被引擎清楚定義的，而不是插件。
引擎通過定義接口來指導插件做什么工作，插件具體實現(xiàn)功能。我們讓插件注冊自己的引擎接口的特殊實現(xiàn)。當然直接創(chuàng)建插件實現(xiàn)類的實例并注冊是比較笨的做法。
這樣使得同一時刻所有可能的實現(xiàn)同時存在，占用內(nèi)存與CPU資源。解決的辦法是工廠類，它唯一的目的是在請求時創(chuàng)建另外類的實例。
如果引擎定義了接口與插件通信，那么也應該為工廠類定義接口：
typename Interface Factory { virtual Interface *create() = 0; }; 
class Renderer { virtual void  beginScene() = 0; virtual void  endScene() = 0;};
typedef  Factory;Renderer; RendererFactory;
選擇1: 插件管理器
接下來應該考慮插件如何在引擎中注冊它們的工廠，引擎又如何實際地使用這些注冊的插件。一種選擇是與存在的代碼很好的接合，
這通過寫插件管理器來完成。這使得我們可以控制哪些組件允許被擴展。
class  PluginManager 
{void  registerRenderer(std::auto_ptr ;RendererFactory ; RF);
void  registerSceneManager(std::auto_ptr ;SceneManagerFactory ; SMF); };
當引擎需要一個渲染器時，它會訪問插件管理器，看哪些渲染器已經(jīng)通過插件注冊了。
然后要求插件管理器創(chuàng)建期望的渲染器，插件管理器于是使用工廠類來生成渲染器，插件管理器甚至不需要知道實現(xiàn)細節(jié)。
插件由動態(tài)庫組成，后者導出一個可以被插件管理器調(diào)用的函數(shù)，用以注冊自己：
void   registerPlugin(PluginManager ;PM);
>插件管理器簡單地在特定目錄下加載所有dll文件，檢查它們是否有一個名為registerPlugin()的導出函數(shù)。
當然也可用xml文檔來指定哪些插件要被加載。　
選擇 2: 完整地集成Fully Integrated 除了使用插件管理器，
也可以從頭設計代碼框架以支持插件。最好的方法是把引擎分成幾個子系統(tǒng)
，構(gòu)建一個系統(tǒng)核心來管理這些子系統(tǒng)。可能像下面這樣：
class Kernel {StorageServer &amp;getStorageServer() const; GraphicsServer &amp;getGraphicsServer() const;};
class StorageServer {<BR><SPAN style="COLOR: #008000">; //提供給插件使用，注冊新的讀檔器
void addArchiveReader(std::auto_ptr&lt;ArchiveReader&gt; AL);// 查詢所有注冊的讀檔器，直到找到可以打開指定格式的讀檔器
 std::auto_ptr&lt;Archive&gt; openArchive(const std::string &amp;sFilename);
<BR>};<BR>&nbsp;<BR>class GraphicsServer {<BR>&nbsp;<SPAN style="COLOR: #008000"> // 供插件使用，用來添加驅(qū)動<BR></SPAN>&nbsp; 
void addGraphicsDriver(std::auto_ptr&lt;GraphicsDriver&gt; AF);<BR>&nbsp; <BR>&nbsp; <SPAN style="COLOR: #008000">// 獲取有效圖形驅(qū)動的數(shù)目
<BR></SPAN>&nbsp; size_t getDriverCount() const;<BR><SPAN style="COLOR: #008000">&nbsp;//返回驅(qū)動<BR></SPAN>&nbsp; 
GraphicsDriver &amp;getDriver(size_t Index);<BR>};<BR>這里有兩個子系統(tǒng)，它們使用” Server”作為后綴。
第一個Server內(nèi)部維護一個有效圖像加載器的列表，每次當用戶希望加載一幅圖片時，圖像加載器被一一查詢，
直到發(fā)現(xiàn)一個特定的實現(xiàn)可以處理特定格式的圖片。另一個子系統(tǒng)有一個GraphicsDrivers的列表，它們作為Renderers的工廠來使用。
可以是Direct3DgraphicsDriver或是OpenGLGraphicsDrivers,它們分別負責Direct3Drenderer與OpenGLRenderer的創(chuàng)建。引擎提供有效的驅(qū)動列表供用戶選擇使用，
通過安裝一個新的插件，新的驅(qū)動也可以被加入。<BR><BR><SPAN style="COLOR: #0000ff">版本</SPAN><BR>在上面兩個可選擇的方法中，
不強制要求你把特定的實現(xiàn)放到插件中。假如你的引擎提供一個讀檔器的默認實現(xiàn)，以支持自定義文件包格式。你可以把它放到引擎本身，
當StorageServer 啟動時自動進行注冊。<BR>現(xiàn)在還有一個問題沒有討論：假如你不小心的話，與引擎不匹配（例如，已經(jīng)過時的）插件會被加載
子系統(tǒng)類的一些變化或是插件管理器的改變足以導致內(nèi)存布局的改變，當不匹配的插件試圖注冊時可能發(fā)生沖突甚至崩潰。比較討厭的是，這些在調(diào)試時難與發(fā)現(xiàn)。
 幸運的是，辨認過時或不正確的插件非常容易。最可靠的是方法是在你的核心系統(tǒng)中放置一個預處理常量。任何插件都有一個函數(shù)，
它可以返回這個常量給引擎：<BR><SPAN style="COLOR: #008000">// Somewhere in your core system<BR>
</SPAN>#define MyEngineVersion 1;<BR>&nbsp;<BR><SPAN style="COLOR: #008000">// The plugin</SPAN><BR>extern int getExpectedEngineVersion()
 {<BR>&nbsp; return MyEngineVersion;<BR>}<BR>在這個常量被編譯到插件后，當引擎中的常量改變時，任何沒有進行重新編譯的插件它的　
getExpectedEngineVersion ()方法會返回以前的那個值。引擎可以根據(jù)這個值，拒絕加載不匹配的插件。為了使插件可以重新工作，必須重新編譯它。
當然，最大的危險是你忘記了更新常量值。無論如何，你應該有個自動版本管理工具幫助你。 </P>