用脫口秀大會來講觀察者模式
大家好，我是悟空。
最近正在熱播的脫口秀大會，想必大家都看過了吧，那這次我來帶著大家來看下大會上的觀察者模式吧。
一、脫口秀
首先是脫口秀的角色劃分：
我們把脫口秀演員：當做一個被被觀察者(Observable)。
4 位領笑員 + 180 位觀眾，當做觀察者(Observer)。
領笑員的職責：當脫口秀演員表現好時，拍燈，表示非常好笑。
觀眾的職責：當脫口秀演員表現好時，拿起手中的遙控器，按下按鍵表示非常喜歡。
這種場景就非常符合觀察者模式了，簡單來說就是一批觀察者對要觀察的對象進行觀察，對觀察對象進行反應。
說完上面的例子，想必大家對觀察者模式已經有了初步的印象了。
那我們再來看看在程序設計的世界中，觀察者模式是怎么樣的。
二、觀察者模式
GoF 設計模式那本書中講到：在對象之間定義一個一對多的依賴，當一個對象狀態改變的時候，所有依賴的對象都會自動收到通知，這就是觀察者模式。
觀察者模式有很多其他稱呼，比如發布訂閱，監聽回調等等，其實只要場景符合上面的描述，都可以叫做觀察者模式。
Java API 內置了觀察者模式，非常方便使用。用法：java.util 包內包含最基本的 Observer 接口(觀察者接口)和 Observable 類(被觀察者父類)。另外他們之間可以用推(push)或拉(pull)的方式傳送數據。
另外很重要的一點：被觀察者和觀察者之間的關系是一對多的。如上面的脫口秀的例子，觀眾是很多個，演員一次只有一個(或一個脫口秀組合)。
三、被觀察者怎么工作的?
只需要這個類繼承 Observable 類即可。我來帶著大家看下這個 Observable 類的構成。
添加觀察者
我們首先想一下，我們想要觀察別人的時候，是不是就需要被添加成別人的觀察者，那么就需要一個添加觀察者的方法，Observale 給我們提供了一個添加成為別人的觀察者的方法：addObserver。
存放觀察者
當有很多想要成為觀察者的時候，是不是就得有個地方專門來存這些觀察者?
Observable 給我們提供了一個存放所有觀察者的地方：一個 Vector 集合。
移除觀察者
當我們不想被某個人觀察，是不是就移除掉就可以了。
Observable 給我們提供了一個移除觀察者的方法：deleteObserver。
被觀察者如何發出通知?
當被觀察對象，想告訴觀察者，他的狀態已經變了，是不是就要發個通知?
Observable 給我們提供了兩個方法：
notifyObservers() 或 notifyObservers(Object arg)。
區別就是一個帶參，一個不帶參。不帶參的方式常用在觀察者通過 pull 的方式來獲取數據。
如下圖所示，通過 push 的方式通知觀察者。
那么通知的具體細節是怎么樣的?
說白了，就三步：
- 被觀察對象，先判斷自己狀態是否有改變。
- 從 vector 集合中獲取所有添加的觀察者。
- 循環遍歷觀察者，調用觀察者的 update 方法。
看下源碼更清晰，注釋都加上了。
- public void notifyObservers(Object var1) {
- Object[] var2;
- synchronized(this) {
- //當調用 setChange() 方法后，this.changed = true
- if (!this.changed) {
- return;
- }
- // 獲取所有觀察者
- var2 = this.obs.toArray();
- // 重置 change 狀態
- this.clearChanged();
- }
- // 循環遍歷通知觀察者
- for(int var3 = var2.length - 1; var3 >= 0; --var3) {
- ((Observer)var2[var3]).update(this, var1);
- }
- }
為什么要有 setChanged?
在被觀察者發送通知前，被觀察對象都會調用下 setChanged() 方法，標記狀態已經改變了。
- protected synchronized void clearChanged() {
- this.changed = false;
- }
那為什么需要調用下這個?不調用可以嗎?
當被觀察對象調用 notifyObservers 方法中，會判斷狀態是否有改變，如果沒有改變，則不會通知觀察者。
這樣做的好處：可以在通知觀察者時有更多的彈性。如果不想持續不斷地通知觀察者，就可以適當地控制 setChanged 方法的調用。
其他：還可以用 clearChanged，重置 changed 狀態，hasChanged 方法獲取 changed 狀態。
四、觀察者如何工作的?
其實很簡單，觀察者實現了 Observer 接口就可以成為觀察者。
- public interface Observer {
- void update(Observable var1, Object var2);
- }
然后觀察者實現了 update 方法，就是給被觀察對象來調用的。
關于推模式和拉模式的小插曲：
如果想用推模式，調用帶參的 notifyObservers 方法把參數傳給觀察者就可以了，如果想用拉模式，就需要主動調用被觀察者的 get 數據的方法，用帶參的或不帶參的方式通知觀察者都是可以的。
五、代碼實現
我們把領笑員定義為 Leader 類，觀眾定義成 Viewer 類，脫口秀演員定義為 Actor 類。
領笑員都在看演員表演脫口秀，需要成為演員的觀察者。調用 actor.addObserver(leader) 就可以了.
觀眾也是類似，調用 actor.addObserver(viewer) 就好了。
根據前面講解的原理，領笑員和觀眾必須繼承 observer 接口，然后實現 update 方法。
如下所示：當收到通知后，做出相應反應，比如拍燈。
演員的每次的梗說完后，都會調用 setChanged() 方法，和 notifyObservers(參數) 來通知觀察者，然后所有觀察者的 update 方法都會被觸發。
來看下演員通知的代碼：
執行結果如下，王勉的表現非常精彩，領笑員拍燈了!
源碼下載，在公眾號后臺回復：觀察者。
好了，觀察者模式還是挺有意思的。那在電商中如何應用的呢?
六、關于設計模式
上面關于觀察者和被觀察者的工作原理有些坑，不知道大家注意到沒?
- 觀察者需要被添加到具體某個被觀察者的集合中，才能觀察，相當于面向細節了，違背了面向抽象的原則。
- Observable 是一個類，而不是一個接口，而且 Observable 也沒有實現接口，這個就違背了面向接口編程。
- 必須有一個類來繼承 Observable ，如果某個類相同時擁有 Observer 類的功能，又想擁有另外一個類的功能，那么就會陷入兩難，因為 Java 不支持多重繼承，限制了 Observable 的復用潛力。
- 另外 Observer API 中的 setChanged() 方法被保護起來了(被定義成 protected 方法)，那么除非繼承 Observable，否則無法創建 Observable 實例并組合到你自己的對象中。違反了“多用組合，少用繼承”的原則。
七、架構設計的問題
問題1：上面的觀察者模式都是同步阻塞的方式，被觀察者需要等待觀察者全部執行完后，才會執行后續代碼。怎么通過異步的方式來通知觀察者呢?
- 方案1：啟動一個線程來調用 notifyObservers 方法。
- 方案2：Google Guava EventBus 框架的設計思想
問題2：跨進程怎么通信?
- 方案1：我們看到被觀察者每次都要調用觀察者的 update 方法來通知觀察者，所以跨進程該怎么做?我們可以同步調用 RPC 接口來實現。
- 方案2：消息隊列，可以有多個消費者和生產者，消費者訂閱消息，類似觀察者。但是引入了消息隊列，增加了維護成本。
問題3：跨機器怎么通信?
- 還是引入消息隊列。
八、電商中應用
商品庫存可以作為一個被觀察者，商品入庫單作為觀察者，當商品庫存變了后，需要生成一個商品入庫單，就可以用觀察者模式，商品入庫單和商品庫存進行解耦，如果后續還要生成其他類型的入庫單再加上發送一條消息給管理員，直接添加觀察者就可以了。
九、后記
本篇通過脫口秀大會來講解觀察者模式，涉及到了三種角色，領笑員，觀眾，脫口秀演員。
然后詳細講解了觀察者和被觀察者的工作原理，另外探討了這種模式有哪些設計模式相關的問題。
然后從架構設計的角度來分析了觀察者模式引入的問題：同步調用，跨進程通信，跨機器通信。
最后簡單講了下電商中的應用場景，拋轉引玉，希望大家留言探討。
本文轉載自微信公眾號「悟空聊架構」，可以通過以下二維碼關注。轉載本文請聯系悟空聊架構公眾號。
