外掛程式式構架設計經驗

1 只建議匯出介面或者函式，使用標準型別變數，不建議匯出複雜的類。

解釋：外掛程式式程式設計就是最大化的解耦，模組全部放置於dll

中，並且每個

dll只匯出標準的載入函式，由載入函式再次匯出模組類介面。標準的載入函式都是

c風格的。匯出的類在修改的時候，不應該需要編譯其他的模組。由於標頭檔案的修改會引發其他模組的重新編譯，因此建議不匯出複雜的類，而採用比較簡單的類，或者介面。在實現時，採用繼承的方式，不破壞介面。

2 dll無法匯出模板類，在匯出類中使用了模板類，也會引起大量的

warning

，因此不建議在匯出介面中使用模板類。

解釋：模板類屬於不確定版本的**，並且是源**編譯。不同版本的模板類實現可能不一樣，這樣就限制了外掛程式開發工具與版本，外掛程式儘量減少這方面的限制，com

做到了只限制作業系統，不限制開發語言，我們一般要做到限制開發語言和開發工具，但不要限制開發工具的版本，外掛程式開發人員可以選擇自己喜歡的類庫。如果限制開發工具版本和庫版本，此條可不算。

3 開發外掛程式式系統，需要有一套好的公共庫

解釋：由於外掛程式式系統由各種模組組成，標準的引數型別已經不夠用，比如字串類，由於盡量不使用模板類，因此各個介面中只能使用原始的字元陣列模式，這在windows api

中非常明顯。如果要做一套好的外掛程式式系統，像字串這種型別，最好自己實現乙個字串類，供各個模組使用。在

mfc庫中，就實現了大量的基礎類，如果我們允許非

mfc庫開發的話，那麼是有必要提供一套這樣的基礎類的。各個外掛程式可以使用自己熟悉的類，但匯出介面中，只能使用公共的類。

4 盡量只提供

ui執行緒給外掛程式

解釋：各個模組都可以有屬於自己的執行緒，但只應該自己使用，盡量不要和其他模組做互動，互動的介面或者函式盡量放在主線程，也就是ui

執行緒中，防止執行緒互鎖問題發生。如果不是必須，主模組盡量不提供多執行緒給外掛程式。

5 避免時間長的函式，如需要使用非同步機制

解釋：由於外掛程式介面的呼叫，基本上都是在主線程中，因此一旦發生某個外掛程式的某個函式超長的問題，會造成介面假死現象，不能因為乙個外掛程式造成如此問題。將同步的函式轉成非同步函式，這個事情放在外掛程式中做比較好，如果主模組來做，造成了多個執行緒被外掛程式使用，有可能發生死鎖。

6 非核心外掛程式不能拋異常

解釋：保證程式穩定執行是每個外掛程式的責任，因為某個外掛程式的問題而拋異常，外掛程式丟擲異常將整個程式崩潰的做法是不可取的。外掛程式應該盡量控制可能出現的問題，並做好自己的處理，不要將問題拋給主模組來處理。我個人也不喜歡**中拋異常的方式，c

工作了這麼多年，沒有異常反而能把問題處理得非常好。

c++語言效率趕不上

c的地方，異常是最拖分的一塊。

7 記憶體誰申請誰釋放

解釋：記憶體的使用和釋放，在effective

等文件中說過，在外掛程式式程式設計中，全部是外掛程式

dll，都不在乙個模組內，因此記憶體的使用和釋放問題更嚴重，這一點要在命名介面的時候，就做到。這一點我們可以模仿

com，各種介面的

delete

都使用release

函式，由各個介面自己去釋放自己，保證不出現申請和釋放不是同乙個模組的問題。

8 資源與多語言支援

現在的軟體系統一般支援多語言模式，外掛程式式系統，一般都採用自定義字串的方式，也就是說字串一般不放置於資源中，而是外部檔案。對於各個模組自己的資源，在使用的時候，也需要小心，不能搞錯了資源，而導致載入其他人定義的資源，從而引起資源混亂。

一軟體體系結構和框架的定義軟體體系結構的英文單詞是 architecture architecture的基本詞義是建築建築學建築風格。軟體體系結構雖然根植於軟體工程，但還處於乙個研究發展的階段，迄今為止還沒有乙個為大家所公認的定義。設計模式中對框架的定義是框架就是一組相互協作的類，對於特定...