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

2021-09-11 09:53:16 字數 1676 閱讀 3145

我曾經在面試中被問道,「觀察者模式和發布訂閱模式的有什麼區別?」 我迅速回憶起「head first設計模式」那本書:

發布 + 訂閱 = 觀察者模式

「我知道了,我知道了,別想騙我」

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

但是面試官笑了,「不,它們不一樣。」

我當時的表情:

所以是我錯了嗎?

之後我回到家開啟google查詢答案。這篇文章就是我google後的總結。

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

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

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

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

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

所以,以上和「觀察者模式」有什麼關係呢?這裡的「香蕉公司」就是subject,用來維護observers(和你一樣的候選人),為某些event(比如職位空缺)來通知(notify)觀察者。

是不是很簡單!?

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

在觀察者模式中的subject就像乙個發布者(publisher)觀察者(observer)完全和訂閱者(subscriber)關聯。subject通知觀察者就像乙個發布者通知他的訂閱者。這也就是很多書和文章使用「發布-訂閱」概念來解釋觀察者設計模式。但是這裡還有另外乙個流行的模式叫做發布-訂閱設計模式。它的概念和觀察者模式非常類似。最大的區別是:

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

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

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

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

有感覺了嗎?

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

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

譯者:繆宇

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

觀察者模式 在軟體設計中是乙個物件,維護乙個依賴列表,當任何狀態發生改變自動通知它們。我們假設你正在找乙份軟體工程師的工作,對 香蕉公司 很感興趣。所以你聯絡了他們的hr,給了他你的聯絡 他保證如果有任何職位空缺都會通知你。這裡還有幾個候選人也你一樣很感興趣。所以職位空缺大家都會知道,如果你回應了他...

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

我曾經在面試中被問道,觀察者模式和發布訂閱模式的有什麼區別?我迅速回憶起 head first設計模式 那本書 發布 訂閱 觀察者模式 我知道了,我知道了,別想騙我 我微笑著回答 沒有區別,它們是一樣的。但是面試官笑了,不,它們不一樣。我當時的表情 所以是我錯了嗎?之後我回到家開啟google查詢答...

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

觀察者模式 observer pattern 和發布訂閱模式 publish subscribe pattern 到底有什麼不同?所謂觀察者模式,其實就是為了實現松耦合 loosely coupled 用 head first設計模式 裡的氣象站為例子,每當氣象測量資料有更新,changed 方法就...