原文地址：zhuanlan.zhihu.com/p/51357583
作者：柳樹

有一回面試，面試官問：

觀察者模式，和釋出訂閱模式，有什麼區別？

我腦海中立刻閃現了《Head First設計模式》裡講的：

Publishers + Subscribers = Observer Pattern

“哼哼，我知道答案了，兄dei！”，我內心無比雞凍。

“它們是一樣的。”，我故作鎮定，嘴角露出一絲微笑，彷彿下一秒鐘面試官就會給我發offer。

面試官也笑了，“不，它們不一樣”。

然後我就：

So, 為什麼我錯了？觀察者模式（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的訂閱者。當然也有可能是訂閱者自己過來拉取，看具體實現。

也就是說，釋出訂閱模式裡，釋出者和訂閱者，不是鬆耦合，而是完全解耦的。

放一張極簡的圖，給大家對比一下這兩個模式的區別：

總結

從表面上看：

• 觀察者模式裡，只有兩個角色 —— 觀察者 + 被觀察者
• 而釋出訂閱模式裡，卻不僅僅只有釋出者和訂閱者兩個角色，還有一個經常被我們忽略的 —— 經紀人Broker

往更深層次講：

• 觀察者和被觀察者，是鬆耦合的關係
• 釋出者和訂閱者，則完全不存在耦合

從使用層面上講：

• 觀察者模式，多用於單個應用內部
• 釋出訂閱模式，則更多的是一種跨應用的模式(cross-application pattern)，比如我們常用的訊息中介軟體

最後，我的所有文字，都是對這篇文章的拙劣模仿：Observer vs Pub-Sub pattern