說說觀察者和發(fā)布訂閱模式的區(qū)別？

來到心儀已久的公司面試，剛推開門還沒等我說話HR 小姐姐就主動(dòng)問我：你是來參加面試的吧？

我心想不對啊：難道是因?yàn)槲议L的帥，小姐姐一眼就看出來我將來是這棟樓的主人，所以才主動(dòng)跟我打招呼。

我昂起頭，略微點(diǎn)點(diǎn)頭：是的。

HR小姐姐：面試官馬上就過來，我先帶你去會議室。

在去會議室的路上，我發(fā)現(xiàn)大家脖子上都帶著亮閃閃的工牌，我下意識的看了看我的脖子上，除了昨天沒有洗澡留下來的一點(diǎn)汗?jié)n啥也沒有。

原來是因?yàn)槲覜]帶工牌才認(rèn)出我的，頓時(shí)我的臉滾燙滾燙的，我承認(rèn)剛才我有點(diǎn)自戀了。

HR小姐姐：怎么了，你臉怎么紅通通的，是不舒服嗎？

我摸了摸臉：沒有沒有，面試有點(diǎn)緊張，害。

來到會議室，HR 小姐姐給我遞過一杯水：面試官臨時(shí)有個(gè)會，你稍微等一會。

我：好的。

我心里咕嚕：怎么突然有個(gè)會，會不會是因?yàn)榭戳宋业暮啔v覺得我菜，故意找了一個(gè)借口，待會肯定讓 HR 過來說面試太忙今天不面了。

果不其然，門開了，一位頭發(fā)油油的滿臉是痘的中年大叔向我走來。

我心想：這不會就是傳說中的架構(gòu)師吧。看來還是很看重我啊，第一面就派一個(gè)架構(gòu)師來面我，我得好好表現(xiàn)一下。

架構(gòu)師：你就是xxx 吧，剛才有個(gè)會議我來晚了，我們開始面試吧，一分鐘簡單介紹一下自己。

果然沒有猜錯(cuò)，給我一分鐘介紹，幸虧之前是按照一分鐘準(zhǔn)備的，我要開始背了。

我張嘴一笑，露出自信的大牙：尊敬的架構(gòu)師你好，我是 xxx，之前在上一家公司擔(dān)任……

架構(gòu)師點(diǎn)點(diǎn)頭：很好。我看你簡歷上寫了很多技能，你挑一個(gè)你最熟悉的。

我有點(diǎn)凌亂了：架構(gòu)師怎么不按套路出牌，應(yīng)該會問我 HashMap 的源碼，Java 鎖的機(jī)制等。我想了想我比較熟悉的：Java 集合類、JVM、多線程、spring 全家桶，我如果說這些肯定會被架構(gòu)師鄙視，差點(diǎn)忘了我還有一個(gè)殺手锏：設(shè)計(jì)模式。

我拍了拍胸脯：架構(gòu)師你好，我之前參與項(xiàng)目重構(gòu)用到了很多設(shè)計(jì)模式，要不你問我設(shè)計(jì)模式的東西吧。

架構(gòu)師：那你說說觀察者模式和發(fā)布訂閱模式的區(qū)別？

我腦海立刻閃現(xiàn)《Head First設(shè)計(jì)模式》里面講的：Publishers + Subscribers = Observer Pattern，問這么簡單的問題難道是看不起我嗎。

我內(nèi)心無比激動(dòng)，嘴角露出勝利者的微笑：親愛的架構(gòu)師，我之前看過一本書《Head First 設(shè)計(jì)模式》，這里面講的觀察者模式和發(fā)布訂閱模式是等同關(guān)系的，它們是一回事。

架構(gòu)師也笑了：不，它們不一樣。

此刻我慌了，雙手有點(diǎn)輕微顫抖，我哪里錯(cuò)了，它們明明是相等的。

架構(gòu)師：我待會還有個(gè)會，要不今天的面試先到這里，你回家等消息吧。

回家后我心不甘，決定要把觀察者模式和發(fā)布訂閱模式搞清楚，通過一頓谷歌后我寫了下面這些筆記：

觀察者模式

觀察者模式一般有觀察者和被觀察者。舉個(gè)例子：大家在學(xué)校上自習(xí)的時(shí)候，等老師走了有些人會玩手機(jī)、吃零食、交頭接耳找隔壁妹妹聊天，但是被老師發(fā)現(xiàn)可就不好了，所以大家想了一個(gè)招，讓坐在最后排的同學(xué)幫忙“放風(fēng)”，老師一來就給大家一個(gè)手勢通知大家，大家就繼續(xù)裝好好學(xué)生（哈嘿）。

這其實(shí)就是一個(gè)典型的觀察者模式，“放風(fēng)”的同學(xué)是被觀察者，玩手機(jī)、吃零食的同學(xué)是觀察者，大家都在觀察“放風(fēng)”同學(xué)的手勢，一旦老師來了，被觀察者就會通知大家。

好了，讓我們看看 UML 建模是如何定義的。

觀察者模式定義對象間一種一對多的依賴關(guān)系，使得每當(dāng)一個(gè)對象改變狀態(tài)，則所有依賴于它的對象都會得到通知并自動(dòng)更新。

UML結(jié)構(gòu)圖如下：


Observer類是抽象觀察者，為所有的具體觀察者定義一個(gè)接口，在得到主題的通知時(shí)更新自己。

ConcreteSubject類是具體主題，將有關(guān)狀態(tài)存入具體觀察者對象，在具體主題內(nèi)部狀態(tài)改變時(shí)，給所有登記過的觀察者發(fā)出通知。

ConcreteObserver是具體觀察者，實(shí)現(xiàn)抽象觀察者角色所要求的更新接口，以便使本身的狀態(tài)與主題的狀態(tài)相協(xié)同。

發(fā)布訂閱模式

舉個(gè)生活中的例子，比如我們想要訂閱一份國家地理雜志，一般需要我們先向郵局申請（付錢），告訴郵局我要訂閱這份雜志，苦等數(shù)日雜志終于印刷好了，這個(gè)時(shí)候我們不會直接跑到印刷廠里去，而是等印刷廠將雜志送給郵局，然后郵局才會慢吞吞地將雜志送到家（推模式），如果你實(shí)在等不及了跑到郵局直接取雜志，恭喜你學(xué)會了“拉模式”。

用專業(yè)術(shù)語來解釋發(fā)布訂閱模式：

訂閱者把自己想訂閱的事件注冊到調(diào)度中心，當(dāng)該事件觸發(fā)時(shí)候，發(fā)布者發(fā)布該事件到調(diào)度中心（順帶上下文），由調(diào)度中心統(tǒng)一調(diào)度訂閱者注冊到調(diào)度中心的處理代碼。

在發(fā)布訂閱模式里發(fā)布者并不會直接通知訂閱者，換句話說發(fā)布者和訂閱者彼此互不感知。

那發(fā)布者和訂閱者如何交流呢？答案是通過中間的調(diào)度中心。

• 發(fā)布者將消息發(fā)送給調(diào)度中心，告訴它你幫我把消息放到 Topic1中。
• 訂閱者告訴調(diào)度中心，我需要訂閱 topic1，你幫我留意一下。
• 當(dāng)有消息來了，訂閱者可以采取拉模式或者推模式來獲取消息。

有態(tài)度的總結(jié)

話不多說，先上一張圖：

從表面上看：

• 觀察者模式里只有兩個(gè)角色：觀察者和被觀察者。
• 發(fā)布訂閱模式里有三種角色：發(fā)布者、訂閱者、調(diào)度器（第三者）。

往更深層次講：

• 觀察者和被觀察者是松耦合的關(guān)系。
• 發(fā)布者和訂閱者則完全不存在耦合。

從使用層面上講：

• 觀察者模式經(jīng)常用于單個(gè)應(yīng)用內(nèi)部。
• 發(fā)布訂閱模式更多是一種跨應(yīng)用的模式(cross-application pattern)，比如我們常用的消息中間件Kafka 等。

綜上：觀察者模式和發(fā)布訂閱模式本質(zhì)上都有發(fā)布訂閱的思想，但是又有一定的區(qū)別，所以我們不能將二者完全等同起來。