不過這種技術介面的制訂是個難題，設計不好很影響以後的功能擴充套件 ——
fking
比較簡單的外掛程式想法，擴充套件的功能是有限的。
應該考慮主程式本身也應該是乙個外掛程式的結構。也就是說外掛程式分為宿主外掛程式和擴充套件外掛程式兩類。這兩類也可以在一起。這樣的話才可能有好的擴充套件性。象eclipse的擴充套件和擴充套件點的思想，和sharpdevelop的外掛程式樹的思想比較好解決了擴充套件性的問題。 ——
jan以上是兩位網友對筆者《c#外掛程式構架實戰》一文作出的評價。首先對兩位熱心的讀者表示感謝。
的確如此，在軟體開發的過程中，設計的過程往往比寫**的過程要難得多。因此，通常除了軟體測試之外，耗時最多的也就是系統建模了。乙個好的軟體系統應當具有較高的穩定性（可靠性）、易操作性以及可擴充套件性支援，尤其是可擴充套件性。我認為，良好的可擴充套件性支援是乙個軟體團隊在開發中變被動為主動的必要條件。對於乙個應用，我們希望在使用者增加需求時，我們能夠用最少的時間、最少的人力來解決問題。當別人在使用者快速增長的需求中忙得不可開交時（
使用者總是不能在第一次需求分析時將需求完完整整的告訴你 ^_^），而你，你的團隊只需要作一點工作就可以讓「貪得無厭」（-_-）的使用者得到滿足，從而提高了效率，讓團隊有更多的的時間來
創造，而不是去做無謂的
修改。很遺憾的是，在《c#外掛程式構架實戰》一文中，我並未考慮到這一點。當然，對於乙個十八歲的沒有也不可能有團隊工作經驗的年輕人來說，這樣的失誤（失誤就是失敗——老師如是說）是可以原諒的（自我開脫之辭）。不過，我決定對這個外掛程式系統進行重構。
考慮到系統的複雜性，這次我準備使用uml（大上個月才開始學的，畫得不好，見笑了）。
1. 著手分析
對於網友 jan 的指教，我大概明了，但人的思維差別太大，我不敢保證我的理解是完全符合 jan 的意思的。但是，我仍然會根據自己對可擴充套件性的理解構建乙個應用程式框架模型。
直入正題。我現在假設我屬於乙個軟體團隊（就暫且叫她 abstractsoft 吧），並任系統分析師（^o^）。任何事物都有它規範的一面，我們希望我們的團隊出品的部署在同一平台的所有應用都有相同的框架，相同的部署形式。這樣便可以形成獨有的
團隊特色，並在競爭中以
效率取勝。因為我們不需要為每一套應用設計不同的框架——這可以節約不少時間！
這樣我需要把程式實現與使用者介面分開到不同的框架中。我的意思是：
以下是乙個簡單的靜態圖(介面和類的成員將在下面詳細闡述)：
2. iconnectableobject
public inte***ce
iconnectable
void
ondestory();
void
onload();
void
run();
} public
enum
connectionresult
public class extendibleversioninfo
// omitted
}
public
int primaryversion }
public int secondaryversion }
public int buildversion }
public string name }
public string versionstring }
get
3. iextendible
public inte***ce
iextendible
4. 使用類工廠建立應用程式和外掛程式的最新版本
我們的主程式以及外掛程式會設計成 internal class 。程式只輸出乙個工廠類，使用者介面通過呼叫 iextendible 介面的 getlatestversion() 方法獲得這些用來完成實際任務的物件的例項,並把它們顯示出來。或者，也可以列舉所有的版本，讓使用者來挑選所需要版本。
5. 可擴充套件性
不得不承認，這樣的方式可擴充套件性仍不是很強。程式需要公升級時同時需要修改提供給使用者的工廠類（雖然介面不變）。為了實現更好的可擴充套件性，可以把簡單工廠模式轉換為工廠方法模式。
6. 宣告
C 實現外掛程式式架構
1.定義外掛程式介面，將其編譯為dll namespace plugininte ce 2 編寫外掛程式，引用上面的dll，實現上面定義的介面，也編譯為dll 外掛程式a namespace plugininte ce 外掛程式b namespace pluginb 3，在程式中使用外掛程式，需要引...
SoarUI 架構改進的選擇
這是一張大致的訊息流程圖 1.為了以後跨平台，訊息系統模仿ms 2.sheet和layer是乙個虛擬的邏輯類 模仿cocos的scene和layer 這裡我sheet具有z屬性，直接控制了 soarwnd視窗的層次，同一層次的全部放在乙個layer中 事件處理的話，依照z的順序依次判定即可。3.有了...
外掛程式架構1
外掛程式框架在一定程度上也叫微核心框架，它的本質就是希望提供一組最核心的功能，而其它功能都可以在此基礎上通過類似外掛程式的技術來擴充套件實現。我在準備開發這個外掛程式框架的時候，首先想到的問題就是，這個 核心 到底該保函哪些東西？外掛程式之間存在什麼樣的互動？以及如何進行互動？我的初步構想如下 這個...