国产精品久久久久久久久鸭,色8激情欧美成人久久综合电,国产精品久久久久一区二区三区

消息耦合還是接口耦合

最近公司準備開發(fā)一個新產(chǎn)品，需要重新設(shè)計一套新的框架，但是就這框架中各模塊的通信方式，大家產(chǎn)生了爭論，主要集中在各模塊的交互方式是消息耦合還是接口耦合。

需求大概這樣，我們需要封裝一套客戶端SDK, 暴露一系列API給外部用，而這套SDK內(nèi)部會有很多模塊組成，這些模塊之間相互會有交互。

第一種設(shè)計是基于接口耦合，框架如下:

這種接口方式的設(shè)計要點是:
a. 各模塊以類似COM組件的方式封裝和暴露接口，也就是說模塊會以接口的形式暴露接口，并且以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. 有一個統(tǒng)一的模塊管理平臺來管理所有模塊，可以通過該平臺查詢和加載需要的模塊，然后后得到相應(yīng)的接口指針進行操作。
c. 各模塊間的交互全都通過直接調(diào)用其他模塊的接口或是訂閱該模塊的Sink來實現(xiàn)。

第二種設(shè)計是基于消息耦合，框架如下:

這種消息方式的設(shè)計要點是:
a. 各個模塊只有一個消息處理接口。

  class IMessageHandler
    {
    public:
        virtual void ProcessMessage(Message& msg) = 0;
    };

b. 中間的消息總線提供消息的訂閱和分發(fā)，各個模塊會向消息總線注冊自己感興趣的消息。
c. 需要調(diào)用某個模塊接口或是觸發(fā)某個事件時，都是通過向消息總線發(fā)送消息的方式, 然后由訂閱消息的模塊執(zhí)行。

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

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

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

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

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

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

呵呵，不知道各位看客會作何選擇？

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

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

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

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

常用鏈接

留言簿(40)

隨筆分類

隨筆檔案

友情鏈接

最新評論

閱讀排行榜

評論排行榜