2010-07-01 140 views
7

有人能指出兩者之間的主要區別嗎?調解員模式與發佈/訂閱

看來,至少在概念上,這兩者是密切相關的。如果我冒險猜測,我會說發佈/訂閱方法是中介模式的一個子集(因爲中介不一定以發佈/訂閱方式使用,但後者似乎需要一種中介目的)。它靠近它嗎?

回答

11

我將如何描述不同之處在於,在調解器中,如果最終應用程序收到消息,您可能會關心它。所以你用這個來保證誰收到這個消息。而在pub/sub中,您只需發佈消息。如果有任何用戶,他們會得到它,但你不在乎。

2

根據this page,發佈 - 訂閱模型是介體模式的實現。

編輯

我應該注意的是,設計模式被稱爲「模式」正因爲有將要執行的每個之間的差異。它們並不是一套規範的形式,因爲它們是人們如何編寫軟件的觀察集合。所以設計沒有任何「嚴格」堅持設計模式的方法。

0

我認爲一個主要的不同點是問題的背景。

雖然問題可能有兩種方式來解決,真正的擔憂是:

1:「多少改變由事件帶來的依賴於一般環境?」

2:「聽衆期望改變的頻率是多少?」

最佳的調解模式的經典案例說明了這一點,你必須有很多組成部分,並各自對其他類似部件的狀態的複雜的相互依存的更新用一個複雜的UI。

雖然你可以用pub/sub模式解決這個問題,其中組件監聽事件幷包含更新所需的邏輯,上下文對象(以及事件)攜帶所有必要的信息。這裏的優勢顯然是適當地封裝了與其內部組件有關的邏輯。缺點是,如果此類組件應該經常更改,那麼您必須在您引入的每個新組件中完全複製此邏輯。

要使用中介器將引入另一個層並從組件中進一步抽象。這些組件變得更薄,因爲它們只處理表示(UI外觀和感覺),因此變得非常容易。我有這種方法唯一的問題是,更新用邏輯現在似乎蔓延到其他組件和系統的任何更新用需要一個改變成分和中介如果組件的行爲也發生變化。

這對我來說是巨大的困境/權衡,我們需要解決的問題。如果我沒有得到任何正確的東西,請糾正我。

1

實施可以是相同的,但在邏輯上它們是不同的(不同的是簡單的,但它是很難看到)。 我會在下面簡單介紹一下。

實際上,在發佈/訂閱模式的實現中,您將至少擁有一個包含方法「發佈」和「訂閱」的對象。 但是你也可以有更多的組件,所以組件之間的通信並不是按照定義來集中的。

在Mediator模式的實現中,您將擁有JUST ONE對象,其中包含方法「publish」和「subscribe」。所以通信是按照定義「集中」的。