文章首發在公眾號（龍臺的技術筆記），之后同步到掘金和個人網站：xiaomage.info
今天講解一篇行為型設計模式，什么是行為型？行為型主要負責設計 類或物件之間的互動，作業中常用的觀察者模式就是一種行為型設計模式
最近在嘗試重構之前寫過的代碼，在重新梳理過業務之后，發現已有的設計場景應該能夠接入到設計模式，而且查看了代碼的提交記錄，更是堅定了此想法
保持之前的一貫作風，想要說明一個設計模式，需要三板斧支撐，什么是觀察者模式？如何使用觀察者模式？專案中應該如何應用？
觀察者設計模式大綱如下：
- 什么是觀察者模式
- 觀察者模式代碼如何寫
- 如何使用觀察者模式結合業務
- Guava EventBus 觀察者模式
- Spring ApplicationEvent 事件模型
- 觀察者模式最后的總結
什么是觀察者模式
觀察者模式 是一種行為設計模式，允許定義一種訂閱通知機制，可以在物件（被觀察者）事件發生時通知多個 “觀察” 該物件的觀察者物件，所以也被稱為 發布訂閱模式
其實我個人而言，不太喜歡使用文字去定義一種設計模式的語意，因為這樣總是難以理解，所以就有了下面生活中的例子，來幫助讀者更好的去理解模式的語意，類圖如下所示：
在舉例說明前，先讓我們熟悉下觀察者模式中的 角色型別 以及代碼示例，觀察者模式由以下幾部分角色組成，可以參考代碼示例去理解，不要被文字描述帶偏
- 主題（被觀察者）（Subject）：抽象主題角色把所有觀察者物件保存在一個容器里，提供添加和移除觀察者介面，并且提供出通知所有觀察者物件介面（也有作者通過
Observable描述） - 具體主題（具體被觀察者）（Concrete Subject）：具體主題角色的職責就是
實作抽象目標角色的介面語意，在被觀察者狀態更改時，給容器內所有注冊觀察者發送狀態通知
public interface Subject {
void register(Observer observer); // 添加觀察者
void remove(Observer observer); // 移除觀察者
void notify(String message); // 通知所有觀察者事件
}
public class ConcreteSubject implements Subject {
private static final List<Observer> observers = new ArrayList();
@Override
public void register(Observer observer) { observers.add(observer); }
@Override
public void remove(Observer observer) { observers.remove(observer); }
@Override
public void notify(String message) { observers.forEach(each -> each.update(message)); }
}
- 抽象觀察者（Observer）：抽象觀察者角色是觀察者的行為抽象，它定義了一個修改介面，當被觀察者發出事件時通知自己
- 具體觀察者（Concrete Observer）：實作抽象觀察者定義的更新介面，可以在被觀察者發出事件時通知自己
public interface Observer {
void update(String message); // String 入參只是舉例, 真實業務不會限制
}
public class ConcreteObserverOne implements Observer {
@Override
public void update(String message) {
// 執行 message 邏輯
System.out.println("接收到被觀察者狀態變更-1");
}
}
public class ConcreteObserverTwo implements Observer {
@Override
public void update(String message) {
// 執行 message 邏輯
System.out.println("接收到被觀察者狀態變更-2");
}
}
我們跑一下上面的觀察者模式示例，如果不出意外的話會將兩個觀察者執行邏輯中的日志列印輸出，如果是平常業務邏輯，抽象觀察者定義的入參是具有業務意義的，大家可以類比專案上使用到的 MQ Message 機制
public class Example {
public static void main(String[] args) {
ConcreteSubject subject = new ConcreteSubject();
subject.register(new ConcreteObserverOne());
subject.register(new ConcreteObserverTwo());
subject.notify("被觀察者狀態改變, 通知所有已注冊觀察者");
}
}
觀察者模式結合業務
因為公司業務場景保密，所以下面我們通過【新警察故事】的電影情節，稍微篡改下劇情，模擬出我們的觀察者模式應用場景
假設：目前我們有三個警察，分別是龍哥、鋒哥、老三，他們受命跟進犯罪嫌疑人阿祖，如果發現犯罪嫌疑人阿祖有動靜，龍哥、峰哥負責實施抓捕行動，老三向警察局搖人，流程圖如下：
如果說使用常規代碼寫這套流程，是能夠實作需求的，一把梭的邏輯可以實作一切需求，但是，如果說下次行動，龍哥讓老三跟著自己實施抓捕，亦或者說龍哥團隊擴張，來了老四、老五、老六...
對比觀察者模式角色定義，老四、老五、老六都是具體的觀察者（Concrete Observer）
如果按照上面的設想，我們通過“一把梭”的方式把代碼寫出來會有什么問題呢？如下：
-
首當其沖，增加了代碼的復雜性，實作類或者說這個方法函式奇大無比，因為隨著警員的擴張，代碼塊會越來越大
-
違背了開閉原則，因為會頻繁改動不同警員的任務，每個警員的任務不是一成不變的，舉個例子來說這次針對疑犯，讓峰哥實施的抓捕行動，下次就可能是疏散民眾，難道每次的更改都需要改動“一把梭”的代碼
第一種我們可以通過，大函式拆小函式 或者 大類拆分為小類 的方式解決代碼負責性問題，但是，開閉原則卻不能避免掉，因為隨著警員（觀察者）的增多及減少，勢必會面臨頻繁改動原函式的情況
當我們面對這種 已知會變動，并且可能會 頻繁變動不固定 的代碼，就要使用抽象思維來進行設計，進而保持代碼的簡潔、可維護
這里使用 Java SpringBoot 專案結構來書寫觀察者模式，代碼最終推送到 Github 倉庫，讀者可以先把倉庫拉下來，因為其中不止示例代碼，還包括 Guava 和 Spring 的觀察者模式實作，GitHub 倉庫地址
首先，定義觀察者模式中的觀察者角色，分別為抽象觀察者介面以及三個具體觀察者實作類，實際業務中，設計模式會和 Spring 框架相結合，所以示例代碼中包含 Spring 相關注解及介面
其次，定義抽象被觀察者介面以及具體被觀察者實作類，同上，被觀察者也需要成為 Spring Bean，托管于 IOC 容器管理
到這里，一個完整的觀察者模式就完成了，但是，細心的讀者會發現這樣的觀察者模式會有一個小問題，這里先不說明，繼續往下看，接下來就需要實際操練一番，注冊這些觀察者，通過被觀察者觸發事件來通知觀察者
如何實作開閉原則
看了應用的代碼之后，函式體過大的問題已經被解決了，我們通過 拆分成為不同的具體的觀察者類 來拆分總體邏輯，但是開閉原則問題呢？這就是上面所說的問題所在，我們目前是通過 顯示的引入具體觀察者模式 來進行添加到被觀察者的通知容器中，如果后續添加警察老四、老五... 越來越多的警察時，還是需要改動原有代碼，問題應該怎么解決呢
其實非常簡單，平常 Web 專案基本都會使用 Spring 框架開發，那自然是要運用其中的特性解決場景問題，我們這里通過 改造具體被觀察者實作開閉原則
如果看過之前作者寫過的設計模式文章，對 InitializingBean 介面不會感到陌生，我們在 afterPropertiesSet 方法中，通過注入的 IOC 容器獲取到所有觀察者物件 并添加至被觀察者通知容器中，這樣的話，觸發觀察者事件，代碼中只需要一行即可完成通知
@PostConstruct
public void executor() {
// 被觀察者觸發事件, 通知所有觀察者
subject.notify("阿祖有行動！");
}
后續如果再有新的觀察者類添加，只需要創建新的類實作抽象觀察者介面即可完成需求，有時候，能夠被封裝起來的不止是 DateUtil 型別的工具類，一些設計模式也可以被封裝，繼而更好的服務開發者靈活運用，這里會分別介紹 Guava#EventBus 以及 Spring#事件模型
同步異步的概念
在介紹 EventBus 和 Spring 事件模型之前，有一道繞不過去的彎，那就是同步執行、異步執行的概念，以及在什么樣的場景下使用同步、異步模型？
-
同步執行：所謂同步執行，指的就是在發出一個請求后，在沒有獲得呼叫結果之前，呼叫者就會等待在當前代碼，直到獲取到呼叫方法的執行結果，才算是結束，總結一句話就是 由呼叫者主動等待這個呼叫的結果，未回傳之前不執行別的操作
-
異步執行：而異步執行恰恰相反，發出呼叫請求后立即回傳，并向下執行代碼，異步呼叫方法一般不會有回傳結果，呼叫之后就可以執行別的操作，一般通過回呼函式的方式通知呼叫者結果
這里給大家舉個例子，能夠很好的反應同步、異步的概念，比如說你想要給體檢醫院打電話預約體檢，你說出自己想要預約的時間后，對面的小姐姐說：“稍等，我查一下時間是否可以”，這個時候如果你 不掛電話，等著小姐姐查完告訴你 之后才掛斷電話，那這就是同步，如果她說稍等需要查一下，你告訴她：“我先掛了，查到結果后再打過來”，那這就是異步+回呼
在我們上面寫的示例代碼上，毋庸置疑是通過同步的形式執行觀察者模式，那是否可以通過異步的方式執行觀察者行為？答案當然是可以，我們可以通過在 觀察者模式行為執行前創建一個執行緒，那自然就是異步的，當然，不太建議你這么做，這樣可能會牽扯出更多的問題，一起來看下 Guava 和 Spring 是如何封裝觀察者模式
Guava EventBus 決議
EventBus 是 Google Guava 提供的訊息發布-訂閱類別庫，是設計模式中的觀察者模式（生產/消費者模型）的經典實作
具體代碼已上傳 GitHub 代碼倉庫，EventBus 實作中包含同步、異步兩種方式，代碼庫中由同步方式實作觀察者模式
因為 EventBus 并不是文章重點，所以這里只會對其原理進行探討，首先 EventBus 是一個同步類別庫，如果需要使用異步的，那就創建時候指定 AsyncEventBus
// 創建同步 EventBus
EventBus eventBus = new EventBus();
// 創建異步 AsyncEventBus
EventBus eventBus = new AsyncEventBus(Executors.newFixedThreadPool(10));
注意一點，創建 AsyncEventBus 需要指定執行緒池，其內部并沒有默認指定，當然也別像上面代碼直接用 Executors 創建，作者是為了圖省事，如果從規范而言，還是消停的使用默認執行緒池構建方法創建 new ThreadPoolExecutor(xxx);
EventBus 同步實作有一個比較有意思的點，觀察者操作同步、異步行為時，均使用 Executor 去執行觀察者內部代碼，那如何保證 Executor 能同步執行呢，Guava 是這么做的：實作 Executor 介面，重寫執行方法，呼叫 run 方法
enum DirectExecutor implements Executor {
INSTANCE;
@Override
public void execute(Runnable command) {
command.run();
}
}
大家有興趣可以去看下 EventBus 原始碼，不是很難理解，作業使用上還是挺方便的，只不過也有不好的地方，因為 EventBus 屬于行程內操作，如果使用異步 AsyncEventBus 執行業務，存在丟失任務的可能
Spring 事件模型
如果想要使用 ApplicationEvent 玩轉觀察者模式，只需要簡單幾步，總結：操作簡單，功能強大
-
創建業務相關的
MyEvent，需要繼承ApplicationEvent，重寫有參建構式 -
定義不同的監聽器（觀察者）比如
ListenerOne實作ApplicationListener<MyEvent>介面，重寫onApplicationEvent方法 -
通過
ApplicationContext#publishEvent方法發布具體事件
Spring 事件與 Guava EventBus 一樣，代碼就不粘貼了，都已經存放到 Github 代碼倉庫，這里重點介紹下 Spring 事件模型的特點，以及使用事項
Spring 事件同樣支持異步編程，需要在具體 Listener 實作類上添加 @Async 注解，支持 Listener 訂閱的順序，比如說有 A、B、C 三個 Listener，可以通過 @Order 注解實作多個觀察者順序消費
作者建議讀者朋友一定要跑下 ApplicationEvent 的 Demo，在使用框架的同時也 要合理的運用框架提供的工具輪子，因為被框架封裝出的功能，一般而言要比自己寫的功能更強大、出現問題的幾率更少，同時，切記不要造重復輪子，除非功能點不滿足的情況下，可以借鑒原有輪子的基礎上開發自己功能
結言
文章通過圖文并茂的方式幫助大家梳理了下觀察者模式的實作方式，更是推出了進階版的 EventBus 以及 ApplicationEvent，相信大家看完之后可以很愉快的在自己專案中玩耍設計模式了，切記哈，要在合理的場景下使用模式，一般而言觀察者模式作用于 觀察者與被觀察者之間的解耦合
最后解答下最早提到的問題，專案中的觀察者模式 應該使用同步模型還是異步模型呢
如果只是使用觀察者模式拆分代碼使其滿足 開閉原則、高內聚低耦合、職責單一 等特性，那么自然是使用同步去做，因為這種方式是最為穩妥，而如果 不關心觀察者執行結果或者考慮性能 等情況，則可以使用異步的方式，通過回呼的方式滿足業務回傳需求
關于觀察者設計模式本文就講到這里，后面會陸續輸出工廠、原型、享元等模式；如果文章對你有幫助那就點個關注支持下吧，祝好，
公眾號：龍臺的技術筆記轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/491779.html
標籤：Java