引言：
在大型項目的開發中，隨著開發進度的進行，我們經常碰到模塊之間耦合度太高的問題：由于開發人員經常要在別的模塊中調用自己實現的功能，經常隨意在某個函數中隨意添加調用代碼，造成了被修改的那個函數體過長，邏輯混亂。另一個問題是隨意包含頭文件：開發人員在開發中經常為了要使用某些類的功能而包含引用類的頭文件造成類之間的耦合度太高，被包含類的頭文件一處輕微修改經常就會引起整個程序大規模的編譯和鏈接，當編譯鏈接時間達到一定程度時，程序員就會被誘導去做不會導致大規模重編譯的改動，而不管改動是否會保持原來的設計。
常規解決方案：
1. 靜態類庫：設計良好的靜態類庫能實現功能上的隔離，無法避免類庫實現 必須重新編譯、鏈接整個應用程序的問題
2. DLL：但仍有自己的缺點：
a) 函數重名問題:我們通過函數名來調用DLL的函數，在并行開發中容易造成函數重名。
b) 依賴：如果采用常見的隱式連接，那DLL每發行了一個新版本都有必要和應用程序重新鏈接一次，因為DLL里面函數的地址可能已經發生了改變。
3. COM：DLL的缺點就是COM的優點。但是實際開發中我們會發現COM太復雜了。要使用COM編程，必須要非常熟悉C++中的COM實現細節, 最好之前要有使用和實現COM對象和服務器的經驗。開發中而且必須從.idl開始工作才能加入接口屬性和方法,對開發和使用都有很高的門檻。
本文的解決方案—簡化的組件編程：
實際上我們只是在開發項目，并不需要跨語言編程，也不需要組件的位置透明性。為了項目而引入COM代價往往太過于巨大。然而COM的內部結構對于大多數程序員是無關的。因此有必要對COM進行簡化以降低編程門檻。使之更符合常規的變成習慣。所以我們借鑒了COM的優秀思想來構建我們的程序架構，使我們的程序能夠像基于COM組件開發那樣的靈活，而開發人員又不需要掌握太多的COM知識。下面我們分步介紹我們的實現過程
一、 總體架構：
l應用程序：軟件的可執行程序(.exe)，通過組件管理器來創建組件，組件創建起來后應用程序直接訪問組件，不再通過組件管理器中轉。
l 組件管理器：整個框架的核心部分，它本身是一個DLL文件。應用程序通過它來創建、管理所有的相關DLL。作用類似與COM中的COM庫。它是應用程序加載的第一個DLL。
l 組件模塊：以DLL實現的分解后功能模塊。軟件的全部功能都在組件中實現，組件與組件之間，組件和應用程序之間并不直接直接耦合，應用程序或一個組件不能直接創建另一個組件的實例，而必須通過組件管理器創建。組件對外并不暴露出類的實現，而僅是通過組件管理器返回接口的指針。
二、 應用程序運行過程：
應用程序的運行序列圖：
1. 主程序啟動：應用程序在啟動階段調用組件管理器啟動應用程序框架。
2. 組件管理器掃描應用程序目錄下所有的DLL文件，并動態加載DLL，根據事先約好的注冊函數名判斷是否是框架組件
3. 查詢組件A實現的接口
4. 組件A返回它實現的全部接口ID（CLSID）。
5. 組件管理器把接口ID和對應的組件文件名登記在內部鏈表中。
6. 同3
7. 同4
8. 同5，
9. 啟動過程結束，控制權交還給主程序
10. 業務功能開始：主程序調用組件管理器，啟動所有自啟動接口
11. 組件管理器查詢內部鏈表，創建自啟動接口（組件B實現了自啟動接口）
12. 組件B在初始化函數中啟動了相關的業務功能。
13. 組件B需要用到接口A,但組件B并不知道誰實現了接口A，于是它調用組件管理器來創建接口A
14. 組件管理器查詢鏈表得知組件A實現了接口A
15. 組件管理器調用組件A的導出函數創建接口A的實例
16. 組件A返回接口A的實例指針
17. 組件管理器將接口A的實例指針傳遞給接口B
18. 組件B調用接口A來完成某一功能
19. 組件B使用完接口A,直接調用接口A的函數來釋放接口A占用的資源
20. 主程序運行結束：調用組件管理器釋放所有組件占用資源
21. 組件管理器釋放所有自啟動接口占用資源。直接調用接口B的函數釋放
22. 組件B釋放完畢
23. 應用程序退出
三、 應用程序的實現：
應用程序的實現比較簡單：僅需在應用程序初始化時加載組件管理器，調用管理器提供的啟動框架，啟動自啟動接口。在退出時調用組件管理器釋放所有組件占用的資源即可
四、 組件管理器：
組件管理器是應用程序和組件之間的橋梁。它維護了一張組件接口鏈表。負責整個框架的啟動、組件的創建、還有最后框架資源的釋放工作。組件管理器雖然重要，但它的實現卻很簡單，這里就不在詳講了。
五、 組件：
組件是整個項目的核心，整個應用程序的所有功能都由組件完成。一般而言一個功能點需要由兩個組件來完成，一個提供功能服務，一個為自啟動組件，調用功能服務。
1. 組件的實現：
l 組件對外只暴露出接口，因此每一個組件至少都由兩部分構成，組件接口和組件的實現類。
a) 組件接口：借鑒COM的思想，每一個接口都有唯一的GUID來標示。
組件接口僅定義了一組類的純虛函數，并不包含實現的任何細節
b) 實現類：是接口的實現。包含全部的實現細節
l 跟COM類似，接口分為單實例和多實例接口。因此需要把創建部分分離出來。創建的代碼很相似，所以可以用模板來實現。將公用代碼寫成靜態庫，每個組件包含一份可以減少組件的代碼編寫量。
組件結構圖
多實例接口的創建過程：
單實例接口的第一次創建過程與多實例一樣。第二次以后的創建為：
結果：
a) 開發獨立：每個模塊可以單獨開發，單獨編譯，甚至可以單獨調試和測試。當所有的組件開發完成后把它們組合在一起就得到了完整的應用系統。當需求發生部分變更時并不需要對所有的組件進行修改，只需修改受影響的組件即可。
b) 修改獨立：新增功能只需將實現的DLL放入應用程序目錄即可，不需更改原有代碼。 除了核心模塊，其余功能拼湊可簡單通過增刪DLL實現
c) 模塊獨立：在開發過程中強迫程序員和接口而不是具體的類打交道，防止出現耦合性很強的代碼。
d) 智能擴展，只需將實現特定接口的COM類(DLL)防入程序所在的目錄,程序自動創建它，可以在類的初始化函數內實現程序功能。
e) 可重用性強，因為是針對接口開發，只要符合接口規范就可以重用DLL
下面我們給出了一個按照仿COM架構實現的Demo
1. 單獨一個Exe也能運行，雖然只是個空殼子沒有功能。
2. 加入ComManager.DLL，于是程序具有了自動擴展功能。
3. 加入了ModuleA.DLL,主界面出現了一個按鈕，右機窗口彈出了一個菜單，按鈕和菜單均可以響應命令。菜單和按鈕的創建和響應命令均在ModuleA.DLL中實現
4. 加入了ModuleB.DLL,主界面出現了另一個按鈕，右機窗口彈出的菜單又多了一項，按鈕和菜單均可以響應命令。新增的菜單和按鈕的創建及響應命令均在ModuleB.DLL中實現
5. 加入Sking.DLL，于是整個程序的界面都具有了膚化效果
6. 加入Log.DLL，于是程序具有了日志功能，可以紀錄模塊創建的順序
7. 。。。。。。。。。。。。。。
8. 。。。。。。。。。。
因為程序是基于接口開發的，所以功能的實現和模塊的名字無關，和模塊加載的順序也無關（有興趣可以試一下）----當然ComManager.DLL必須是第一個加載，并且不能更名。