C#實現插件構架淺析
C#語言有很多值得學習的地方，這里我們主要介紹C#實現插件構架，包括介紹幾個解決方案的對比等方面。
假設你設計的程序已經部署到用戶的計算機上，并且能夠正常運行了。但是有一天，用戶打來了電話——他們要求增加新的功能。確定了用戶的需求后，你竟然發現原有的軟件架構已經無法勝任新增任務的需求——你需要重新設計這個應用了！但問題是，就算你又用了一個開發周期完成了用戶需要的應用，卻不能保證用戶的需求不會再次變更。也就是說，需求蔓延的可能性依然存在。因此，這種情況下C#實現插件構架更能顯示出它的優越性。
一. 幾個解決方案的對比
我總結了一下我所接觸到的C#實現插件構架，大致上可分為以下幾類：
1.腳本式
使用某種語言把插件的程序邏輯寫成腳本代碼。而這種語言可以是 Python ，或是其他現存的已經經過用戶長時間考驗的腳本語言。甚至，你可以自行設計一種腳本語言來配合你程序的特殊需要。當然，用當今***的 XML 是再合適不過了。
這種形式的特點在于，稍有點編程知識的用戶就可以自行修改你的腳本（ ^_^ 假如你不加密它的話）。我們無法論證這是好處還是壞處。因為，這種情況所造成的后果是不可預知的。
2.動態函數庫 DLL
插件功能以動態庫函數的形式存在。主程序通過某種渠道（插件編寫者或某些工具）獲得插件 DLL 中的函數簽名，然后在合適的地方調用它們。用過 Matlab 的讀者都知道， Matlab 中的各項功能幾乎都是些動態鏈入的函數。
3.聚合式
顧名思義，就是把插件功能直接寫成 EXE 。主程序除了完成自己的職責外，還負責調度這些“插件”。我不喜歡這種形式。這使插件與插件之間，主程序與插件之間（主要是這一點）的信息交流困難了許多。巴比倫塔的失敗 [1] 從某種程度上講就是信息交流無法實現造成的。
4.COM 組件
COM [2] 的產生給這個世界增添了幾分活力。只有接口！我們的插件需要做的只是實現程序定義的接口。主程序不需要知道插件怎樣實現預定的功能，它只需要通過接口訪問插件，并提供主程序相關對象的接口。這樣一來，主程序與各插件之間的信息交流就變得異常簡單。并且，插件對于主程序來說是完全透明的。
二. 決策
C# 是面向對象的程序設計語言。它提供了 interface 關鍵字來直接定義接口。同時， System.Reflection 命名空間也提供了訪問外部程序集的一系列相關對象。這就為我們在C#實現插件構架打下了堅實的基礎。
【編輯推薦】
