觀察者模式 vs 釋出訂閱模式
有一回面試，面試官問：
觀察者模式，和釋出訂閱模式，有什麼區別？
我腦海中立刻閃現了《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)，比如我們常用的訊息中介軟體
最後，我的所有文字，都是對這篇文章的拙劣模仿： ofollow,noindex" target="_blank">Observer vs Pub-Sub pattern
- Java-AQS/" rel="nofollow,noindex" target="_blank">
Previous
Java AQS無碼講解