摘自
https://www.cnblogs.com/BOT-Man/p/7637308.html
https://cloud.tencent.com/developer/article/1612544
觀察者vs中介者
-
觀察者 (observer) 模式和 中介者 (mediator) 模式
- 調用流程非常相似
- 網上相關資料、代碼對兩者區別的解釋不夠清楚
- 兩個設計模式在 圖形界面 (GUI) 編程中，被廣泛使用
- 學習的過程是：不知道 -> 知道 -> 能向別人解釋清楚
基本概念
首先需要知道 回調函數的基本概念 。。
觀察者 (observer) 模式
- 通過 訂閱-發布 (subscribe-publish) 模型，消除組件之間雙向依賴
- 消息的 發布者 (subject) 不需要知道 觀察者 (observer) 的存在
- 兩者只需要約定消息的格式（如何訂閱、如何發布），就可以通信
- 筆記鏈接
中介者 (mediator) 模式
- 通過設置 消息中心 (message center)，避免組件之間直接依賴
- 所有的 協同者 (colleague) 只能通過 中介者 (mediator) 進行通信，
而相互之間不知道彼此的存在 - 當各個組件的消息出現循環時，消息中心可以消除組件之間的依賴混亂
- 筆記鏈接
兩者的聯系
- 中介者模式 一般通過 觀察者模式 實現
- 協同者 作為 發布者，中介者 作為 觀察者
- 協同者 發布消息 -> 中介者 收到并處理消息 -> 中介者 直接發送消息給 協同者
- 協同者 不依賴于 中介者
- 當組件之間依賴關系簡單時，可以直接使用 觀察者模式
- 當組件之間依賴關系復雜是，需要借助 中介者模式 梳理關系
觀察者vs發布訂閱
3、發布訂閱模式
（1）理解
當你了解了觀察者模式房東—租客這種模型以后，你會發現，如果觀察者很多，那么房東壓力還是挺大的，比如收錢的壓力。
這個時候，房東每天簽合同、收房租跑斷腿，不堪其擾，于是就去拜托中介，交給中介打理省心，于是就有了類似于房東—中介—租客的這種發布訂閱模式。
（2）實踐
首先我們需要定義一下中介機構：
-
EventBus這個就是相當于扮演了中介機構的角色。 -
emit發布就相當于是房東。房東不定時隨機的發布消息，說某某套房子空了。 -
on訂閱就相當于是房客，訂閱某個戶型的事件了以后就可以實時收到該戶型的通知。
4、小結
- 通過上面這些示例，兩者之間最大的區別就是
中介結構這一環，通過這個機構，房東和房客之間的溝通更加的順暢了，也就是兩者之間松耦合，這樣的話，我們開發的時候可以將中介結構抽離成為了一個單獨的文件，這樣使得業務邏輯更加清晰，維護起來也更加的區別。不管這兩者模式是相同還是不同的，這個我覺得是最主要的區別。 - 其它的我這里直接引用這篇文章的小結概況一下吧，我覺得這位大佬總結還是比較到位的：
- 在觀察者模式中，觀察者是知道Subject的，Subject一直保持對觀察者進行記錄。然而，在發布訂閱模式中，發布者和訂閱者不知道對方的存在。它們只有通過消息代理進行通信。
- 在發布訂閱模式中，組件是松散耦合的，正好和觀察者模式相反。
- 觀察者模式大多數時候是同步的，比如當事件觸發，Subject就會去調用觀察者的方法。而發布-訂閱模式大多數時候是異步的（使用消息隊列）。
- 觀察者 模式需要在單個應用程序地址空間中實現，而發布-訂閱更像交叉應用模式。
- 當然，以上這些都是我自己的理解，歡迎交流。
參考學習： https://juejin.im/post/5a14e9edf265da4312808d86 https://molunerfinn.com/observer-vs-pubsub-pattern https://juejin.im/post/5bb1bb616fb9a05d2b6dccfa https://juejin.im/post/57de12355bbb50005e648bd8
