亚洲美日韩Av中文字幕无码久久久妻妇 ,国产成人久久777777,996久久国产精品线观看

消息耦合還是接口耦合

最近公司準(zhǔn)備開(kāi)發(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組件的方式封裝和暴露接口，也就是說(shuō)模塊會(huì)以接口的形式暴露接口，并且以Sink的方式通知外部事件。比如模塊A的接口如下

class IA
{
public:
    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)一的模塊管理平臺(tái)來(lái)管理所有模塊，可以通過(guò)該平臺(tái)查詢和加載需要的模塊，然后后得到相應(yīng)的接口指針進(jìn)行操作。
c. 各模塊間的交互全都通過(guò)直接調(diào)用其他模塊的接口或是訂閱該模塊的Sink來(lái)實(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ì)向消息總線注冊(cè)自己感興趣的消息。
c. 需要調(diào)用某個(gè)模塊接口或是觸發(fā)某個(gè)事件時(shí)，都是通過(guò)向消息總線發(fā)送消息的方式, 然后由訂閱消息的模塊執(zhí)行。

上面2種架構(gòu)的設(shè)計(jì)方式各有優(yōu)劣，下面我們來(lái)簡(jiǎn)單比較一下:
(1)耦合性: 盡管基于接口的耦合已經(jīng)降低了耦合性，但是相比消息來(lái)說(shuō)，顯然是消息方式耦合性更弱。
(2)可擴(kuò)展性: 某個(gè)模塊新增加一個(gè)接口，接口方式需要新加接口函數(shù)，而消息方式只需要新加一個(gè)消息類型。即使新增加一個(gè)模塊，消息方式只是新增加幾個(gè)消息處理類型，非常方便。所以可擴(kuò)展性來(lái)說(shuō)，顯然也是消息方式占優(yōu)。
(3)性能: 接口方式是直接調(diào)用，可是消息方式需要經(jīng)過(guò)消息總線過(guò)濾分發(fā)，顯然性能上接口方式更高。
(4)編碼安全性，接口方式是強(qiáng)類型，接口一修改，編譯時(shí)就能很快發(fā)現(xiàn)問(wèn)題；消息方式卻是弱類型，消息修改后，有可能要到運(yùn)行時(shí)才能發(fā)現(xiàn)問(wèn)題，另外很多消息內(nèi)容要做強(qiáng)制了類型轉(zhuǎn)換才能使用。
(5)文檔要求: 顯然接口方式相對(duì)比較清晰，消息的話每個(gè)消息都要詳細(xì)定義，并且嚴(yán)格按照該定義執(zhí)行。
(6)可調(diào)試性: 顯然接口方式要方便些，消息很可能不小心就會(huì)引起混亂。
(7)監(jiān)控過(guò)濾方便性：消息方式走同一總線，可以很方便的增加過(guò)濾和監(jiān)控功能，接口方式則因?yàn)楦鱾€(gè)模塊interface和Sink各不相同，增加這些功能沒(méi)那么方便。
(8)跨線程或是跨進(jìn)程，甚至跨機(jī)器調(diào)用：顯然接口方式基本做不到，消息方式的話只要修改總線就可以做到。
(9)異步支持: 消息方式可以很方便的支持異步，接口方式則做不到。

經(jīng)過(guò)上面的比較，我們可以得出一些結(jié)論：
消息方式的強(qiáng)項(xiàng)是耦合性和擴(kuò)展性，以及監(jiān)控的方便性，個(gè)人感覺(jué)比較適合于Server端的大規(guī)模應(yīng)用。
接口方式的強(qiáng)項(xiàng)是性能高效以及開(kāi)發(fā)的方便性，比較適用于同一進(jìn)程內(nèi)客戶端的小規(guī)模應(yīng)用。

但是大部分時(shí)候，對(duì)于架構(gòu)師或是公司領(lǐng)導(dǎo)，他們會(huì)更關(guān)注可耦合性和可擴(kuò)展性，所以他們會(huì)傾向于選擇消息方式，盡管有時(shí)可能不是那么適用。

另外，個(gè)人覺(jué)得編譯時(shí)靜態(tài)類型檢測(cè)是C++的優(yōu)勢(shì)，能讓我們高效而可靠的開(kāi)發(fā)程序，我們不應(yīng)該放棄這些優(yōu)勢(shì)而去把C++當(dāng)作弱類型的動(dòng)態(tài)語(yǔ)言來(lái)使用，我在軟命令接口的適用場(chǎng)合一文也有相關(guān)描述。

最后，對(duì)于該框架的設(shè)計(jì)，其實(shí)我個(gè)人傾向于上面2種方式的結(jié)合，即各個(gè)模塊的入接口（調(diào)用接口）走接口方式，而各模塊內(nèi)部觸發(fā)的事件走消息總線的方式，雖然沒(méi)人采用這種方式，還是在這里記錄一下。

一個(gè)多月了，消息還是接口，領(lǐng)導(dǎo)們老大們關(guān)于走何種架構(gòu)還在爭(zhēng)論中...

呵呵，不知道各位看客會(huì)作何選擇？

posted on 2012-10-12 22:50 Richard Wei 閱讀(4619) 評(píng)論(5) 編輯收藏引用所屬分類: 架構(gòu)體系

只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
【推薦】100%開(kāi)源！大型工業(yè)跨平臺(tái)軟件C++源碼提供，建模，組態(tài)！

相關(guān)文章: 客戶端UI層設(shè)計(jì)的思考客戶端架構(gòu)設(shè)計(jì)的簡(jiǎn)單總結(jié) 接口繼承中一個(gè)常見(jiàn)問(wèn)題的思考常見(jiàn)體系結(jié)構(gòu)介紹理解 Windows API 調(diào)用過(guò)程消息耦合還是接口耦合

網(wǎng)站導(dǎo)航: 博客園 IT新聞 BlogJava 博問(wèn) Chat2DB 管理

常用鏈接

留言簿(40)

隨筆分類

隨筆檔案

友情鏈接

最新評(píng)論

閱讀排行榜

評(píng)論排行榜