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

我曾經在面試中被問道，_「觀察者模式和發佈訂閱模式的有什麼區別？」 _我迅速回憶起「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 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。