1. 程式人生 > >觀察者模式 vs 發布-訂閱模式

觀察者模式 vs 發布-訂閱模式

ring google 流程 ted 工程 工作 例子 輸入 文章

我曾經在面試中被問道,_“觀察者模式和發布訂閱模式的有什麽區別?” _我迅速回憶起“Head First設計模式”那本書:

發布 + 訂閱 = 觀察者模式

“我知道了,我知道了,別想騙我”

技術分享圖片

我微笑著回答:“沒有區別,它們是一樣的。”

但是面試官笑了,“不,它們不一樣。”

我當時的表情:

技術分享圖片

所以是我錯了嗎? 之後我回到家打開google查找答案。這篇文章就是我google後的總結。

在深入探討區別之前,我們先來討論下“觀察者模式”和“發布訂閱模式”。

觀察者設計模式:

我認為大多數人都會同意觀察者模式是學起來最好入門的,因為你從字面意思就能知道它主要是做什麽的。

觀察者模式 在軟件設計中是一個對象,維護一個依賴列表,當任何狀態發生改變自動通知它們。

看吧,即使是維基百科的定義 ,也不是很難, 對吧? 如果你還不清楚,那讓我用通俗易懂的來解釋。

我們假設你正在找一份軟件工程師的工作,對“香蕉公司”很感興趣。所以你聯系了他們的HR,給了他你的聯系電話。他保證如果有任何職位空缺都會通知你。這裏還有幾個候選人也你一樣很感興趣。所以職位空缺大家都會知道,如果你回應了他們的通知,他們就會聯系你面試。

所以,以上和“觀察者模式”有什麽關系呢?這裏的“香蕉公司”就是Subject

,用來維護Observers(和你一樣的候選人),為某些event(比如職位空缺)來**通知(notify)**觀察者。

是不是很簡單!?

技術分享圖片

所以,如果你想在你的軟件或者應用中實現觀察者模式,你可以遵循上圖這個流程。(我不想在我的文章中寫任何代碼,因為網上有數不清的例子)

發布-訂閱設計模式

在觀察者模式中的Subject就像一個發布者(Publisher)觀察者(Observer)完全和訂閱者(Subscriber)關聯。subject通知觀察者就像一個發布者通知他的訂閱者。這也就是很多書和文章使用“發布-訂閱”概念來解釋觀察者設計模式。但是這裏還有另外一個流行的模式叫做

發布-訂閱設計模式。它的概念和觀察者模式非常類似。最大的區別是:

技術分享圖片

在發布-訂閱模式,消息的發送方,叫做發布者(publishers),消息不會直接發送給特定的接收者,叫做訂閱者

意思就是發布者和訂閱者不知道對方的存在。需要一個第三方組件,叫做信息中介,它將訂閱者和發布者串聯起來,它過濾和分配所有輸入的消息。換句話說,發布-訂閱模式用來處理不同系統組件的信息交流,即使這些組件不知道對方的存在。

那麽如何過濾消息的呢?事實上這裏有幾個過程,最流行的方法是:基於主題以及基於內容。好了,就此打住,如果你感興趣,可以去維基百科了解。

技術分享圖片

發布-訂閱模式(圖片來源: MSDN 博客)

所以,我用下圖表示這兩個模式最重要的區別:

技術分享圖片

圖片來源: developers-club

有感覺了嗎?

我們把這些差異快速總結一下:

  • 觀察者模式中,觀察者是知道Subject的,Subject一直保持對觀察者進行記錄。然而,在發布訂閱模式中,發布者和訂閱者不知道對方的存在。它們只有通過消息代理進行通信。

  • 發布訂閱模式中,組件是松散耦合的,正好和觀察者模式相反。

  • 觀察者模式大多數時候是同步的,比如當事件觸發,Subject就會去調用觀察者的方法。而發布-訂閱模式大多數時候是異步的(使用消息隊列)。

  • 觀察者 模式需要在單個應用程序地址空間中實現,而發布-訂閱更像交叉應用模式。

盡管它們之間有區別,但有些人可能會說發布-訂閱模式是觀察者模式的變異,因為它們概念上是相似的。

ok,我想說的說完了,希望你get到了,感謝您的閱讀,如果發現有什麽錯誤或者需要修改的地方,請在下方留言,謝謝!

原文地址:https://hackernoon.com/observer-vs-pub-sub-pattern-50d3b27f838c 譯者:繆宇


作者:繆宇
鏈接:https://juejin.im/post/5a14e9edf265da4312808d86
來源:掘金
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請註明出處。

觀察者模式 vs 發布-訂閱模式