消息耦合還是接口耦合

1、消息耦合還是接口耦合最近公司準備開發(fā)一個新產(chǎn)品，需要重新設(shè)計一套新的框架，但是就這框架中各 模塊的通信方式，大家產(chǎn)生了爭論，主要集中在各模塊的交互方式是消息耦合還 是接口耦合。需求大概這樣，我們需要封裝一套客戶端SDK,暴露一系列API給外部用，而這 套SDK內(nèi)部會有很多模塊組成，這些模塊之間相互會有交互。第一種設(shè)計是基于接口耦合，框架如下:這種接口方式的設(shè)計要點是：各模塊以類似COM組件的方式封裝和暴露接口，也就是說模塊會以接口的形 式暴露接口，并且以Sink的方式通知外部事件。比如模塊A的接口如下class IApublic:virtual void fun1() = 0;virtual

2、void fun2() = 0;virtual void int AdviseSink(IASink* pSink) = 0;virtual void bool UnAdviseSink(int nCooki) = 0;class IASinkpublic:virtual void Event1() = 0;virtual void Event2() = 0;)有一個統(tǒng)一的模塊管理平臺來管理所有模塊，可以通過該平臺查詢和加載需 要的模塊，然后后得到相應(yīng)的接口指針進行操作。各模塊間的交互全都通過直接調(diào)用其他模塊的接口或是訂閱該模塊的Sink來 實現(xiàn)。第二種設(shè)計是基于消息耦合，框架如下:這種消息方

3、式的設(shè)計要點是：a.各個模塊只有一個消息處理接口。class IMessageHandler(public:virtual void ProcessMessage(Message& msg) = 0;);中間的消息總線提供消息的訂閱和分發(fā)，各個模塊會向消息總線注冊自己感 興趣的消息。需要調(diào)用某個模塊接口或是觸發(fā)某個事件時，都是通過向消息總線發(fā)送消 息的方式，然后由訂閱消息的模塊執(zhí)行。上面2種架構(gòu)的設(shè)計方式各有優(yōu)劣，下面我們來簡單比較一下：耦合性：盡管基于接口的耦合已經(jīng)降低了耦合性，但是相比消息來說，顯然 是消息方式耦合性更弱?？蓴U展性：某個模塊新增加一個接口，接口方式需要新加接口函數(shù)，而消息

4、方式只需要新加一個消息類型。即使新增加一個模塊，消息方式只是新增加幾個 消息處理類型，非常方便。所以可擴展性來說，顯然也是消息方式占優(yōu)。性能：接口方式是直接調(diào)用，可是消息方式需要經(jīng)過消息總線過濾分發(fā)，顯 然性能上接口方式更高。編碼安全性，接口方式是強類型，接口一修改，編譯時就能很快發(fā)現(xiàn)問題； 消息方式卻是弱類型，消息修改后，有可能要到運行時才能發(fā)現(xiàn)問題，另外很 多消息內(nèi)容要做強制了類型轉(zhuǎn)換才能使用。文檔要求：顯然接口方式相對比較清晰，消息的話每個消息都要詳細定義， 并且嚴格按照該定義執(zhí)行?？烧{(diào)試性：顯然接口方式要方便些，消息很可能不小心就會引起混亂。監(jiān)控過濾方便性：消息方式走同一總線，可以很方

5、便的增加過濾和監(jiān)控功能， 接口方式則因為各個模塊interface和Sink各不相同，增加這些功能沒那么方便?？缇€程或是跨進程，甚至跨機器調(diào)用：顯然接口方式基本做不到，消息方式 的話只要修改總線就可以做到。經(jīng)過上面的比較，我們可以得出一些結(jié)論：消息方式的強項是耦合性和擴展性，以及監(jiān)控的方便性，個人感覺比較適合于 Server端的大規(guī)模應(yīng)用。接口方式的強項是性能高效以及開發(fā)的方便性，比較適用于同一進程內(nèi)客戶端 的小規(guī)模應(yīng)用。但是大部分時候，對于架構(gòu)師或是公司領(lǐng)導，他們會更關(guān)注可耦合性和可擴展 性，所以他們會傾向于選擇消息方式，盡管有時可能不是那么適用。另外，個人覺得編譯時靜態(tài)類型檢測是C+的優(yōu)勢，能讓我們高效而可靠的開 發(fā)程序，我們不應(yīng)該放棄這些優(yōu)勢而去把C+當作弱類型的動態(tài)語言來使用， 我在軟命令接口的適用場合一文也有相關(guān)描述。最后，對于該框架的設(shè)計，其實我個人傾向于上面2種方式的結(jié)合，即各個模 塊的入接口(調(diào)用接口)走接口方式，而各模塊內(nèi)部觸發(fā)的事件走消息總線