跟著 Guava、Spring 學習如何設計觀察者模式

語言: CN / TW / HK

文章首發在公眾號(龍臺的技術筆記),之後同步到掘金和個人網站:xiaomage.info

今天講解一篇行為型設計模式,什麼是行為型?行為型主要負責設計 類或物件之間的互動。工作中常用的觀察者模式就是一種行為型設計模式

最近在嘗試重構之前寫過的程式碼。在重新梳理過業務之後,發現已有的設計場景應該能夠接入到設計模式,而且查看了程式碼的提交記錄,更是堅定了此想法

保持之前的一貫作風,想要說明一個設計模式,需要三板斧支撐。什麼是觀察者模式?如何使用觀察者模式?專案中應該如何應用?

觀察者設計模式大綱如下:

  1. 什麼是觀察者模式
  2. 觀察者模式程式碼如何寫
  3. 如何使用觀察者模式結合業務
  4. Guava EventBus 觀察者模式
  5. Spring ApplicationEvent 事件模型
  6. 觀察者模式最後的總結

什麼是觀察者模式

觀察者模式 是一種行為設計模式,允許定義一種訂閱通知機制,可以在物件(被觀察者)事件發生時通知多個 “觀察” 該物件的觀察者物件,所以也被稱為 釋出訂閱模式

其實我個人而言,不太喜歡使用文字去定義一種設計模式的語義,因為這樣總是難以理解。所以就有了下面生活中的例子,來幫助讀者更好的去理解模式的語義。類圖如下所示:

在舉例說明前,先讓我們熟悉下觀察者模式中的 角色型別 以及程式碼示例。觀察者模式由以下幾部分角色組成,可以參考程式碼示例去理解,不要被文字描述帶偏

  • 主題(被觀察者)(Subject):抽象主題角色把所有觀察者物件儲存在一個容器裡,提供新增和移除觀察者介面,並且提供出通知所有觀察者物件介面(也有作者通過 Observable 描述)
  • 具體主題(具體被觀察者)(Concrete Subject):具體主題角色的職責就是實現抽象目標角色的介面語義,在被觀察者狀態更改時,給容器內所有註冊觀察者傳送狀態通知

```java public interface Subject { void register(Observer observer); // 新增觀察者 void remove(Observer observer); // 移除觀察者 void notify(String message); // 通知所有觀察者事件 }

public class ConcreteSubject implements Subject { private static final List 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):實現抽象觀察者定義的更新介面,可以在被觀察者發出事件時通知自己

```java 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 機制

java 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)

如果按照上面的設想,我們通過“一把梭”的方式把程式碼寫出來會有什麼問題呢?如下:

  1. 首當其衝,增加了程式碼的複雜性。實現類或者說這個方法函式奇大無比,因為隨著警員的擴張,程式碼塊會越來越大

  2. 違背了開閉原則,因為會頻繁改動不同警員的任務。每個警員的任務不是一成不變的,舉個例子來說這次針對疑犯,讓峰哥實施的抓捕行動,下次就可能是疏散民眾,難道每次的更改都需要改動“一把梭”的程式碼

第一種我們可以通過,大函式拆小函式 或者 大類拆分為小類 的方式解決程式碼負責性問題。但是,開閉原則卻不能避免掉,因為隨著警員(觀察者)的增多及減少,勢必會面臨頻繁改動原函式的情況

當我們面對這種 已知會變動,並且可能會 頻繁變動不固定 的程式碼,就要使用抽象思維來進行設計,進而保持程式碼的簡潔、可維護

這裡使用 Java SpringBoot 專案結構來書寫觀察者模式,程式碼最終推送到 Github 倉庫。讀者可以先把倉庫拉下來,因為其中不止示例程式碼,還包括 Guava 和 Spring 的觀察者模式實現,GitHub 倉庫地址

首先,定義觀察者模式中的觀察者角色,分別為抽象觀察者介面以及三個具體觀察者實現類。實際業務中,設計模式會和 Spring 框架相結合,所以示例程式碼中包含 Spring 相關注解及介面

其次,定義抽象被觀察者介面以及具體被觀察者實現類。同上,被觀察者也需要成為 Spring Bean,託管於 IOC 容器管理

到這裡,一個完整的觀察者模式就完成了。但是,細心的讀者會發現這樣的觀察者模式會有一個小問題,這裡先不說明,繼續往下看。接下來就需要實際操練一番,註冊這些觀察者,通過被觀察者觸發事件來通知觀察者

如何實現開閉原則

看了應用的程式碼之後,函式體過大的問題已經被解決了,我們通過 拆分成為不同的具體的觀察者類 來拆分總體邏輯。但是開閉原則問題呢?這就是上面所說的問題所在,我們目前是通過 顯示的引入具體觀察者模式 來進行新增到被觀察者的通知容器中,如果後續新增警察老四、老五... 越來越多的警察時,還是需要改動原有程式碼,問題應該怎麼解決呢

其實非常簡單,平常 Web 專案基本都會使用 Spring 框架開發,那自然是要運用其中的特性解決場景問題。我們這裡通過 改造具體被觀察者實現開閉原則

如果看過之前作者寫過的設計模式文章,對 InitializingBean 介面不會感到陌生,我們在 afterPropertiesSet 方法中,通過注入的 IOC 容器獲取到所有觀察者物件 並新增至被觀察者通知容器中。這樣的話,觸發觀察者事件,程式碼中只需要一行即可完成通知

java @PostConstruct public void executor() { // 被觀察者觸發事件, 通知所有觀察者 subject.notify("阿祖有行動!"); }

後續如果再有新的觀察者類新增,只需要建立新的類實現抽象觀察者介面即可完成需求。有時候,能夠被封裝起來的不止是 DateUtil 型別的工具類,一些設計模式也可以被封裝,繼而更好的服務開發者靈活運用。這裡會分別介紹 Guava#EventBus 以及 Spring#事件模型

同步非同步的概念

在介紹 EventBusSpring 事件模型之前,有一道繞不過去的彎,那就是同步執行、非同步執行的概念,以及在什麼樣的場景下使用同步、非同步模型?

  • 同步執行:所謂同步執行,指的就是在發出一個請求後,在沒有獲得呼叫結果之前,呼叫者就會等待在當前程式碼。直到獲取到呼叫方法的執行結果,才算是結束。總結一句話就是 由呼叫者主動等待這個呼叫的結果,未返回之前不執行別的操作

  • 非同步執行:而非同步執行恰恰相反,發出呼叫請求後立即返回,並向下執行程式碼。非同步呼叫方法一般不會有返回結果,呼叫之後就可以執行別的操作,一般通過回撥函式的方式通知呼叫者結果

這裡給大家舉個例子,能夠很好的反應同步、非同步的概念。比如說你想要給體檢醫院打電話預約體檢,你說出自己想要預約的時間後,對面的小姐姐說:“稍等,我查一下時間是否可以”,這個時候如果你 不掛電話,等著小姐姐查完告訴你 之後才結束通話電話,那這就是同步。如果她說稍等需要查一下,你告訴她:“我先掛了,查到結果後再打過來”,那這就是非同步+回撥

在我們上面寫的示例程式碼上,毋庸置疑是通過同步的形式執行觀察者模式,那是否可以通過非同步的方式執行觀察者行為?答案當然是可以。我們可以通過在 觀察者模式行為執行前建立一個執行緒,那自然就是非同步的。當然,不太建議你這麼做,這樣可能會牽扯出更多的問題。一起來看下 Guava 和 Spring 是如何封裝觀察者模式

Guava EventBus 解析

EventBusGoogle Guava 提供的訊息釋出-訂閱類庫,是設計模式中的觀察者模式(生產/消費者模型)的經典實現

具體程式碼已上傳 GitHub 程式碼倉庫,EventBus 實現中包含同步、非同步兩種方式,程式碼庫中由同步方式實現觀察者模式

因為 EventBus 並不是文章重點,所以這裡只會對其原理進行探討。首先 EventBus 是一個同步類庫,如果需要使用非同步的,那就建立時候指定 AsyncEventBus

```java // 建立同步 EventBus EventBus eventBus = new EventBus();

// 建立非同步 AsyncEventBus EventBus eventBus = new AsyncEventBus(Executors.newFixedThreadPool(10)); ```

注意一點,建立 AsyncEventBus 需要指定執行緒池,其內部並沒有預設指定。當然也別像上面程式碼直接用 Executors 建立,作者是為了圖省事,如果從規範而言,還是消停的使用預設執行緒池構建方法建立 new ThreadPoolExecutor(xxx);

EventBus 同步實現有一個比較有意思的點。觀察者操作同步、非同步行為時,均使用 Executor 去執行觀察者內部程式碼,那如何保證 Executor 能同步執行呢。Guava 是這麼做的:實現 Executor 介面,重寫執行方法,呼叫 run 方法

```java enum DirectExecutor implements Executor { INSTANCE;

@Override
public void execute(Runnable command) {
    command.run();
}

} ```

大家有興趣可以去看下 EventBus 原始碼,不是很難理解,工作使用上還是挺方便的。只不過也有不好的地方,因為 EventBus 屬於程序內操作,如果使用非同步 AsyncEventBus 執行業務,存在丟失任務的可能

Spring 事件模型

如果想要使用 ApplicationEvent 玩轉觀察者模式,只需要簡單幾步。總結:操作簡單,功能強大

  1. 建立業務相關的 MyEvent,需要繼承 ApplicationEvent,重寫有參建構函式

  2. 定義不同的監聽器(觀察者)比如 ListenerOne 實現 ApplicationListener<MyEvent> 介面,重寫 onApplicationEvent 方法

  3. 通過 ApplicationContext#publishEvent 方法釋出具體事件

Spring 事件與 Guava EventBus 一樣,程式碼就不貼上了,都已經存放到 Github 程式碼倉庫。這裡重點介紹下 Spring 事件模型的特點,以及使用事項

Spring 事件同樣支援非同步程式設計,需要在具體 Listener 實現類上新增 @Async 註解。支援 Listener 訂閱的順序,比如說有 A、B、C 三個 Listener。可以通過 @Order 註解實現多個觀察者順序消費

作者建議讀者朋友一定要跑下 ApplicationEvent 的 Demo,在使用框架的同時也 要合理的運用框架提供的工具輪子,因為被框架封裝出的功能,一般而言要比自己寫的功能更強大、出現問題的機率更少。同時,切記不要造重複輪子,除非功能點不滿足的情況下,可以借鑑原有輪子的基礎上開發自己功能

結言

文章通過圖文並茂的方式幫助大家梳理了下觀察者模式的實現方式,更是推出了進階版的 EventBus 以及 ApplicationEvent,相信大家看完之後可以很愉快的在自己專案中玩耍設計模式了。切記哈,要在合理的場景下使用模式,一般而言觀察者模式作用於 觀察者與被觀察者之間的解耦合

最後解答下最早提到的問題,專案中的觀察者模式 應該使用同步模型還是非同步模型呢

如果只是使用觀察者模式拆分程式碼使其滿足 開閉原則、高內聚低耦合、職責單一 等特性,那麼自然是使用同步去做,因為這種方式是最為穩妥。而如果 不關心觀察者執行結果或者考慮效能 等情況,則可以使用非同步的方式,通過回撥的方式滿足業務返回需求

關於觀察者設計模式本文就講到這裡,後面會陸續輸出工廠、原型、享元等模式;如果文章對你有幫助那就點個關注支援下吧,祝好。