前言
《設計模式實戰》系列目前已經寫了 7 篇了,最近幾篇平均閱讀保持 1.1k+,後面也會延續之前的高質量,歡迎繼續關注
今天講解一篇行爲型設計模式,什麼是行爲型?行爲型主要負責設計 類或對象之間的交互。工作中常用的觀察者模式就是一種行爲型設計模式
最近在嘗試重構之前寫過的代碼。在重新梳理過業務之後,發現已有的設計場景應該能夠接入到設計模式,而且查看了代碼的提交記錄,更是堅定了此想法
保持之前的一貫作風,想要說明一個設計模式,需要三板斧支撐。什麼是觀察者模式?如何使用觀察者模式?項目中應該如何應用?
觀察者設計模式大綱如下:
- 什麼是觀察者模式
- 觀察者模式代碼如何寫
- 如何使用觀察者模式結合業務
- 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));
<font color='#FF0000'>注意一點</font>,創建 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 事件模型
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
,相信大家看完之後可以很愉快的在自己項目中玩耍設計模式了。切記哈,要在合理的場景下使用模式,一般而言觀察者模式作用於 觀察者與被觀察者之間的解耦合
最後解答下最早提到的問題,項目中的觀察者模式 應該使用同步模型還是異步模型呢
如果只是使用觀察者模式拆分代碼使其滿足 開閉原則、高內聚低耦合、職責單一 等特性,那麼自然是使用同步去做,因爲這種方式是最爲穩妥。而如果 不關心觀察者執行結果或者考慮性能 等情況,則可以使用異步的方式,通過回調的方式滿足業務返回需求
關於觀察者設計模式本文就講到這裏,後面會陸續輸出工廠、原型、享元等模式;如果文章對你有幫助那就點個關注支持下吧,祝好。