c#外掛程式構架實戰 http://blog.csdn.net/jery_lee/archive/2004/08/01/57951.aspx
c#外掛程式構架實戰
visual c#外掛程式構架實戰補遺
主題：visual c#外掛程式構架實戰補遺
在軟體開發的過程中，設計的過程往往比寫**的過程要難得多。因此，通常除了軟體測試之外，耗時最多的也就是系統建模了。乙個好的軟體系統應當具有較高的穩定性（可靠性）、易操作性以及可擴充套件性支援，尤其是可擴充套件性。我認為，良好的可擴充套件性支援是乙個軟體團隊在開發中變被動為主動的必要條件。對於乙個應用，我們希望在使用者增加需求時，我們能夠用最少的時間、最少的人力來解決問題。當別人在使用者快速增長的需求中忙得不可開交時（使用者總是不能在第一次需求分析時將需求完完整整的告訴你），而你，你的團隊只需要作一點工作就可以讓「貪得無厭」的使用者得到滿足，從而提高了效率，讓團隊有更多的的時間來創造，而不是去做無謂的修改。
很遺憾的是，在《c#外掛程式構架實戰》一文中，我並未考慮到這一點。當然，對於乙個十八歲的沒有也不可能有團隊工作經驗的年輕人來說，這樣的失誤（失誤就是失敗——老師如是說）是可以原諒的（自我開脫之辭）。不過，我決定對這個外掛程式系統進行重構。
考慮到系統的複雜性，這次我準備使用uml（大上個月才開始學的，畫得不好，見笑了）。
1. 著手分析
對於網友 jan 的指教，我大概明了，但人的思維差別太大，我不敢保證我的理解是完全符合 jan 的意思的。但是，我仍然會根據自己對可擴充套件性的理解構建乙個應用程式框架模型。
直入正題。我現在假設我屬於乙個軟體團隊（就暫且叫她 abstractsoft 吧），並任系統分析師。任何事物都有它規範的一面，我們希望我們的團隊出品的部署在同一平台的所有應用都有相同的框架，相同的部署形式。這樣便可以形成獨有的團隊特色，並在競爭中以效率取勝。因為我們不需要為每一套應用設計不同的框架——這可以節約不少時間！
這樣我需要把程式實現與使用者介面分開到不同的框架中。我的意思是：
以下是乙個簡單的靜態圖(介面和類的成員將在下面詳細闡述)：
2. iconnectableobject
3. iextendible
public inte***ce iextendible
4. 使用類工廠建立應用程式和外掛程式的最新版本
我們的主程式以及外掛程式會設計成 internal class 。程式只輸出乙個工廠類，使用者介面通過呼叫 iextendible 介面的 getlatestversion() 方法獲得這些用來完成實際任務的物件的例項,並把它們顯示出來。或者，也可以列舉所有的版本，讓使用者來挑選所需要版本。
5. 可擴充套件性
不得不承認，這樣的方式可擴充套件性仍不是很強。程式需要公升級時同時需要修改提供給使用者的工廠類（雖然介面不變）。為了實現更好的可擴充套件性，可以把簡單工廠模式轉換為工廠方法模式。
（visual c#外掛程式構架實戰補遺
the end）
C 外掛程式構架實戰
c 外掛程式構架實戰 visual c 外掛程式構架實戰補遺 主題 visual c 外掛程式構架實戰補遺 在軟體開發的過程中，設計的過程往往比寫 的過程要難得多。因此，通常除了軟體測試之外，耗時最多的也就是系統建模了。乙個好的軟體系統應當具有較高的穩定性 可靠性 易操作性以及可擴充套件性支援，尤其...
Visual C 外掛程式構架實戰 一
一 引言 1.問題的引入 假設你設計的程式已經部署到使用者的計算機上，並且能夠正常執行了。但是有一天，使用者打來了 他們要求增加新的功能。確定了使用者的需求後，你竟然發 現原有的軟體架構已經無法勝任新增任務的需求 你需要重新設計這個應用了！但問題是，就算你又用了乙個開發周期完成了使用者需要的應用，卻...
Visual C 外掛程式構架實戰（二）
二 設計過程 好了，現在我們準備把所有的核心 都放在 cspluginkernel 命名空間中。用vside建立乙個c 類庫工程。在命名空間 cspluginkernel 中開始我們的 1.介面設計 我們的程式編輯器會向外掛程式開放正在編輯的文件物件。程式啟動後，就列舉每乙個外掛程式並把它連線到主程...