[[356449]]

本文轉(zhuǎn)載自微信公眾號「愛笑的架構(gòu)師」，作者雷架。轉(zhuǎn)載本文請聯(lián)系愛笑的架構(gòu)師公眾號。  

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

我心想不對?。弘y道是因為我長的帥，小姐姐一眼就看出來我將來是這棟樓的主人，所以才主動跟我打招呼。

我昂起頭，略微點點頭：是的。

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

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

原來是因為我沒帶工牌才認出我的，頓時我的臉滾燙滾燙的，我承認剛才我有點自戀了。

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

我摸了摸臉：沒有沒有，面試有點緊張，害。

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

我：好的。

我心里咕嚕：怎么突然有個會，會不會是因為看了我的簡歷覺得我菜，故意找了一個借口，待會肯定讓 HR 過來說面試太忙今天不面了。

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

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

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

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

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

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

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

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

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

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

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

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

此刻我慌了，雙手有點輕微顫抖，我哪里錯了，它們明明是相等的。

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

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

觀察者模式

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

這其實就是一個典型的觀察者模式，“放風”的同學是被觀察者，玩手機、吃零食的同學是觀察者，大家都在觀察“放風”同學的手勢，一旦老師來了，被觀察者就會通知大家。

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

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

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

Subject類是主題，它把所有對觀察者對象的引用文件存在了一個集合里，每個主題都可以有任何數(shù)量的觀察者。它是一個抽象主題，提供了一個可以增加和刪除觀察者對象的接口。

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

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

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

發(fā)布訂閱模式

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

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

訂閱者把自己想訂閱的事件注冊到調(diào)度中心，當該事件觸發(fā)時候，發(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，你幫我留意一下。

當有消息來了，訂閱者可以采取拉模式或者推模式來獲取消息。

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

話不多說，先上一張圖：

從表面上看：

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

往更深層次講：

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

從使用層面上講：

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

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

閑聊：冬天到了一起抱團取暖吧~ 大家有任何技術(shù)問題、職業(yè)發(fā)展方向問題都可以加我的個人微信號咨詢，想進讀者群可以備注”加群“，群里人可好了，微信搜索 smileCoder1024 值得擁有。