訊息耦合還是介面耦合
最近公司準備開發乙個新產品，需要重新設計一套新的框架，但是就這框架中各模組的通訊方式，大家產生了爭論，主要集中在各模組的互動方式是訊息耦合還是介面耦合。
需求大概這樣，我們需要封裝一套客戶端sdk, 暴露一系列api給外部用，而這套sdk內部會有很多模組組成，這些模組之間相互會有互動。
第一種設計是基於介面耦合，框架如下:
這種介面方式的設計要點是:
a. 各模組以類似com元件的方式封裝和暴露介面，也就是說模組會以介面的形式暴露介面，並且以sink的方式通知外部事件。比如模組a的介面如下
class
iaclass
iasink
b. 有乙個統一的模組管理平台來管理所有模組，可以通過該平台查詢和載入需要的模組，然後後得到相應的介面指標進行操作。
c. 各模組間的互動全都通過直接呼叫其他模組的介面或是訂閱該模組的sink來實現。
第二種設計是基於訊息耦合，框架如下:
這種訊息方式的設計要點是:
a. 各個模組只有乙個訊息處理介面。
class
imessagehandler;
b. 中間的訊息匯流排提供訊息的訂閱和分發，各個模組會向訊息匯流排註冊自己感興趣的訊息。
c. 需要呼叫某個模組介面 或是 觸發某個事件時，都是通過向訊息匯流排傳送訊息的方式, 然後由訂閱訊息的模組執行。
上面2種架構的設計方式各有優劣，下面我們來簡單比較一下:
(1)耦合性: 儘管基於介面的耦合已經降低了耦合性，但是相比訊息來說，顯然是訊息方式耦合性更弱。
(2)可擴充套件性: 某個模組新增加乙個介面， 介面方式需要新加介面函式，而訊息方式只需要新加乙個訊息型別。即使新增加乙個模組，訊息方式只是新增加幾個訊息處理型別，非常方便。所以可擴充套件性來說，顯然也是訊息方式佔優。
(3)效能: 介面方式是直接呼叫，可是訊息方式需要經過訊息匯流排過濾分發， 顯然效能上介面方式更高。
(4)編碼安全性，介面方式是強型別，介面一修改，編譯時就能很快發現問題；訊息方式卻是弱型別，訊息修改後，有可能要到執行時才能發現問題， 另外很多訊息內容要做強制了型別轉換才能使用。
(5)文件要求: 顯然介面方式相對比較清晰，訊息的話每個訊息都要詳細定義，並且嚴格按照該定義執行。
(6)可除錯性: 顯然介面方式要方便些，訊息很可能不小心就會引起混亂。
(7)監控過濾方便性：訊息方式走同一匯流排，可以很方便的增加過濾和監控功能， 介面方式則因為各個模組inte***ce和sink各不相同，增加這些功能沒那麼方便。
(8)跨執行緒或是跨程序，甚至跨機器呼叫：顯然介面方式基本做不到，訊息方式的話只要修改匯流排就可以做到。
經過上面的比較， 我們可以得出一些結論：
訊息方式的強項是耦合性和擴充套件性，以及監控的方便性，個人感覺比較適合於server端的大規模應用。
介面方式的強項是效能高效以及開發的方便性， 比較適用於同一程序內客戶端的小規模應用。
但是大部分時候， 對於架構師或是公司領導，他們會更關注可耦合性和可擴充套件性，所以他們會傾向於選擇訊息方式，儘管有時可能不是那麼適用。
另外，個人覺得編譯時靜態型別檢測是c++的優勢，能讓我們高效而可靠的開發程式，我們不應該放棄這些優勢而去把c++當作弱型別的動態語言來使用，我在
軟命令介面的適用場合
一文也有相關描述。
最後，對於該框架的設計，其實我個人傾向於上面2種方式的結合， 即各個模組的入介面（呼叫介面）走介面方式，而各模組內部觸發的事件走訊息匯流排的方式，雖然沒人採用這種方式，還是在這裡記錄一下。
乙個多月了，訊息還是介面，領導們老大們關於走何種架構還在爭論中， 我等小兵就默默等待吧 ...
呵呵，不知道各位看客會作何選擇？
耦合還是解耦合？
我們的許多設計思想中很多地方都體現了解耦合的思想，這是 b 應對易於變化 b 的一種很好的解決手段，而在這些手段中最重要的解決方法就是 b 新增中間層 b 所謂新增中間層 比如我們常見的面向介面程式設計，其實就是新增了乙個中間的層次，遮蔽掉了一些變化，還有就是我們常用的設計模式，什麼 啊，faced...
耦合，緊耦合，松耦合，解耦
一 耦合 耦合是兩個或多個模組之間的相互關聯。在軟體工程中，兩個模組之間的耦合度越高，維護成本越高。因此，在系統架構的設計過程中，應減少各個模組之間的耦合度，以提高應用的可維護性。二 緊耦合 緊耦合架構本質是client server的模型，如下圖所示 優點是 架構簡單 設計簡單 開發周期短 能夠快...
資料耦合與控制耦合
資料耦合 其中乙個模組的輸出作為另乙個模組的輸入，那麼就存在資料耦合.如 module a中 int funa module b中 int b funa 上面兩個modules就存在資料耦合.控制耦合 其中乙個模組可以控制另乙個模組的行為.如 module a中 void funa bool fla...