消息耦合還是接口耦合

《消息耦合還是接口耦合》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。

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

2、ic:????virtual?void?fun1()?=?0;????virtual?void?fun2()?=?0;????.????virtual?void?int?AdviseSink(IASink*?pSink)?=?0;????virtual?void?bool?UnAdviseSink(int?nCooki)?=?0;}class?IASink{public:????virtual?void?Event1()?=?0;????virtual?void?Event2()?=?0;????.}b.有一個(gè)統(tǒng)一的模塊管

3、理平臺(tái)來管理所有模塊，可以通過該平臺(tái)查詢和加載需要的模塊，然后后得到相應(yīng)的接口指針進(jìn)行操作。c.各模塊間的交互全都通過直接調(diào)用其他模塊的接口或是訂閱該模塊的Sink來實(shí)現(xiàn)。第二種設(shè)計(jì)是基于消息耦合，框架如下:這種消息方式的設(shè)計(jì)要點(diǎn)是:a.各個(gè)模塊只有一個(gè)消息處理接口。????class?IMessageHandler????{????public:????????virtual?void?ProcessMessage(Message&?msg)?=?0;????};b.中間的消息總線提供消息的訂閱和分發(fā)，各個(gè)模塊會(huì)向消息總

4、線注冊(cè)自己感興趣的消息。c.需要調(diào)用某個(gè)模塊接口或是觸發(fā)某個(gè)事件時(shí)，都是通過向消息總線發(fā)送消息的方式,然后由訂閱消息的模塊執(zhí)行。上面2種架構(gòu)的設(shè)計(jì)方式各有優(yōu)劣，下面我們來簡(jiǎn)單比較一下:(1)耦合性:盡管基于接口的耦合已經(jīng)降低了耦合性，但是相比消息來說，顯然是消息方式耦合性更弱。(2)可擴(kuò)展性:某個(gè)模塊新增加一個(gè)接口，接口方式需要新加接口函數(shù)，而消息方式只需要新加一個(gè)消息類型。即使新增加一個(gè)模塊，消息方式只是新增加幾個(gè)消息處理類型，非常方便。所以可擴(kuò)展性來說，顯然也是消息方式占優(yōu)。(3)性能:接口方式是直接調(diào)用，可是消息方式

5、需要經(jīng)過消息總線過濾分發(fā)，顯然性能上接口方式更高。?(4)編碼安全性，接口方式是強(qiáng)類型，接口一修改，編譯時(shí)就能很快發(fā)現(xiàn)問題；消息方式卻是弱類型，消息修改后，有可能要到運(yùn)行時(shí)才能發(fā)現(xiàn)問題，另外很多消息內(nèi)容要做強(qiáng)制了類型轉(zhuǎn)換才能使用。(5)文檔要求:顯然接口方式相對(duì)比較清晰，消息的話每個(gè)消息都要詳細(xì)定義，并且嚴(yán)格按照該定義執(zhí)行。(6)可調(diào)試性:顯然接口方式要方便些，消息很可能不小心就會(huì)引起混亂。(7)監(jiān)控過濾方便性：消息方式走同一總線，可以很方便的增加過濾和監(jiān)控功能，接口方式則因?yàn)楦鱾€(gè)模塊interface和Sink各不相同，

6、增加這些功能沒那么方便。(8)跨線程或是跨進(jìn)程，甚至跨機(jī)器調(diào)用：顯然接口方式基本做不到，消息方式的話只要修改總線就可以做到。經(jīng)過上面的比較，我們可以得出一些結(jié)論：消息方式的強(qiáng)項(xiàng)是耦合性和擴(kuò)展性，以及監(jiān)控的方便性，個(gè)人感覺比較適合于Server端的大規(guī)模應(yīng)用。接口方式的強(qiáng)項(xiàng)是性能高效以及開發(fā)的方便性，比較適用于同一進(jìn)程內(nèi)客戶端的小規(guī)模應(yīng)用。但是大部分時(shí)候，對(duì)于架構(gòu)師或是公司領(lǐng)導(dǎo)，他們會(huì)更關(guān)注可耦合性和可擴(kuò)展性，所以他們會(huì)傾向于選擇消息方式，盡管有時(shí)可能不是那么適用。另外，個(gè)人覺得編譯時(shí)靜態(tài)類型檢測(cè)是C++的優(yōu)勢(shì)，能讓我們高效

7、而可靠的開發(fā)程序，我們不應(yīng)該放棄這些優(yōu)勢(shì)而去把C++當(dāng)作弱類型的動(dòng)態(tài)語言來使用，我在?軟命令接口的適用場(chǎng)合?一文也有相關(guān)描述。最后，對(duì)于該框架的設(shè)計(jì)，其實(shí)我個(gè)人傾向于上面2種方式的結(jié)合，即各個(gè)模塊的入接口（調(diào)用接口）走接口方式，而各模塊內(nèi)部觸發(fā)的事件走消息總線的方式，雖然沒人采用這種方式，還是在這里記錄一下。一個(gè)多月了，消息還是接口，領(lǐng)導(dǎo)們老大們關(guān)于走何種架構(gòu)還在爭(zhēng)論中，我等小兵就默默等待吧...呵呵，不知道各位看客會(huì)作何選擇？