觀察者模式 vs 發布訂閱模式

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

也就是說，發布訂閱模式裡，發布者和訂閱者，不是松耦合，而是完全解耦的。

從表面上看：

往更深層次講：

從使用層面上講：

**：