一.觀察者模式

所謂觀察者模式，其實就是為了實現鬆耦合(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)，比如我們常用的訊息中介軟體