一、引言
1. 問題的引入
假設你設計的程式已經部署到使用者的計算機上，並且能夠正常執行了。但是有一天，使用者打來了**——他們要求增加新的功能。確定了使用者的需求後，你竟然發 現原有的軟體架構已經無法勝任新增任務的需求——你需要重新設計這個應用了！但問題是，就算你又用了乙個開發周期完成了使用者需要的應用，卻不能保證使用者的 需求不會再次變更。也就是說，需求蔓延的可能性依然存在。因此，這種情況下外掛程式構架更能顯示出它的優越性。
2. 幾個解決方案的對比
我總結了一下我所接觸到的外掛程式構架，大致上可分為以下幾類：
i> 指令碼式
使用某種語言把外掛程式的程式邏輯寫成指令碼** 。而這種語言可以是 python ，或是其他現存的已經經過使用者長時間考驗 的指令碼語言。甚至，你可以自行設計一種指令碼語言來配合你程式的特殊需要。當然，用當今最流行的 xml 是再合適不過了。
這種形式的特點在於，稍有點程式設計知識的使用者就可以自行修改你的指令碼（ ^_^ 假如你不加密它的話）。我們無**證這是好處還是壞處。因為，這種情況所造成的後果是不可預知的。
ii> 動態函式庫 dll
外掛程式功能以動態庫函式的形式存在。主程式通過某種渠道（外掛程式編寫者或某些工具）獲得外掛程式 dll 中的函式簽名，然後在合適的地方呼叫它們。用過 matlab 的讀者都知道， matlab 中的各項功能幾乎都是些動態鏈入的函式。
iii> 聚合式
顧名思義，就是把外掛程式功能直接寫成 exe 。主程式除了完成自己的職責外，還負責排程這些「外掛程式」。我不喜歡這種形式。這使外掛程式與外掛程式之間，主程式與外掛程式之間（主要是這一點）的資訊交流困難了許 多。巴比倫塔的失敗 [1] 從某種程度上講就是資訊交流無法實現造成的。
iv> com 元件
com [2] 的產生給這個世界增添了幾分活力。只有介面！我們的外掛程式需要做的只是實現程式定義的介面。主程式不需要知道外掛程式怎樣實現預定的功能，它只需要通過介面訪問 外掛程式，並提供主程式相關物件的介面。這樣一來，主程式與各外掛程式之間的資訊交流就變得異常簡單。並且，外掛程式對於主程式來說是完全透明的。
3. 決策
c# 是物件導向的程式設計 語言。它提供了 inte***ce 關鍵字來直接定義介面。同時， system.reflection 命名空間也提供了訪問外部程式集的一系列相關物件。這就為我們在 c# 中實現外掛程式構架打下了堅實的基礎。
下面，我們將以乙個具有外掛程式構架的程式編輯 器為例，來闡述這種構架在 c# 中的實現
Visual C 外掛程式構架實戰（二）
二 設計過程 好了，現在我們準備把所有的核心 都放在 cspluginkernel 命名空間中。用vside建立乙個c 類庫工程。在命名空間 cspluginkernel 中開始我們的 1.介面設計 我們的程式編輯器會向外掛程式開放正在編輯的文件物件。程式啟動後，就列舉每乙個外掛程式並把它連線到主程...
Visual C 外掛程式構架實戰 三）
2.外掛程式資訊的儲存與獲取 乙個外掛程式需要有它的名稱 版本等資訊。作為設計者的你，也一定要留下你的尊姓大名和個人 等用來宣傳自己。c 的新特性 屬性，就是乙個很好的解決方案。因此我們定義乙個從 system.attribute 繼承來的類 plugininfoarrtibute 用來指定乙個外掛...
C 外掛程式構架實戰
c 外掛程式構架實戰 http blog.csdn.net jery lee archive 2004 08 01 57951.aspx c 外掛程式構架實戰 visual c 外掛程式構架實戰補遺 主題 visual c 外掛程式構架實戰補遺 在軟體開發的過程中，設計的過程往往比寫 的過程要難得多...