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

2022-09-19 12:09:10 字數 1329 閱讀 9629

觀察者模式(observer pattern),和發布訂閱模式(publish–subscribe pattern),到底有什麼不同?

所謂觀察者模式,其實就是為了實現松耦合(loosely coupled)。

用《head first設計模式》裡的氣象站為例子,每當氣象測量資料有更新,changed()方法就會被呼叫,於是我們可以在changed()方法裡面,更新氣象儀器上的資料,比如溫度、氣壓等等。

但是這樣寫有個問題,就是如果以後我們想在changed()方法被呼叫時,更新更多的資訊,比如說濕度,那就要去修改changed()方法的**,這就是緊耦合的壞處。

怎麼解決呢?使用觀察者模式,面向介面程式設計,實現松耦合。

觀察者模式裡面,changed()方法所在的例項物件,就是被觀察者(subject,或者叫observable),它只需維護一套觀察者(observer)的集合,這些observer實現相同的介面,subject只需要知道,通知observer時,需要呼叫哪個統一方法就好了:

這裡就不貼**了,網上已經有大量的資料。

大概很多人都和我一樣,覺得發布訂閱模式裡的publisher,就是觀察者模式裡的subject,而subscriber,就是observer。publisher變化時,就主動去通知subscriber。

其實並不是。

在發布訂閱模式裡,發布者,並不會直接通知訂閱者,換句話說,發布者和訂閱者,彼此互不相識。

互不相識?那他們之間如何交流?

答案是,通過第三者,也就是在訊息佇列裡面,我們常說的經紀人broker。

發布者只需告訴broker,我要發的訊息,topic是aaa;

訂閱者只需告訴broker,我要訂閱topic是aaa的訊息;

於是,當broker收到發布者發過來訊息,並且topic是aaa時,就會把訊息推送給訂閱了topic是aaa的訂閱者。當然也有可能是訂閱者自己過來拉取,看具體實現。

也就是說,發布訂閱模式裡,發布者和訂閱者,不是松耦合,而是完全解耦的。

從表面上看:

往更深層次講:

從使用層面上講:

**:

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

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

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

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

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

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