Guava和Spring怎么抽象觀察者模式

本篇內容主要講解“Guava和Spring怎么抽象觀察者模式”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Guava和Spring怎么抽象觀察者模式”吧!

什么是觀察者模式

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

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

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

• 主題(被觀察者)(Subject)：抽象主題角色把所有觀察者對象保存在一個容器里，提供添加和移除觀察者接口，并且提供出通知所有觀察者對象接口(也有作者通過  Observable 描述)

• 具體主題(具體被觀察者)(Concrete  Subject)：具體主題角色的職責就是實現(xiàn)抽象目標角色的接口語義，在被觀察者狀態(tài)更改時，給容器內所有注冊觀察者發(fā)送狀態(tài)通知

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)：抽象觀察者角色是觀察者的行為抽象，它定義了一個修改接口，當被觀察者發(fā)出事件時通知自己

• 具體觀察者(Concrete Observer)：實現(xiàn)抽象觀察者定義的更新接口，可以在被觀察者發(fā)出事件時通知自己

public interface Observer {     void update(String message);  // String 入參只是舉例, 真實業(yè)務不會限制 }  public class ConcreteObserverOne implements Observer {     @Override     public void update(String message) {         // 執(zhí)行 message 邏輯         System.out.println("接收到被觀察者狀態(tài)變更-1");     } }  public class ConcreteObserverTwo implements Observer {     @Override     public void update(String message) {         // 執(zhí)行 message 邏輯         System.out.println("接收到被觀察者狀態(tài)變更-2");     } }

我們跑一下上面的觀察者模式示例，如果不出意外的話會將兩個觀察者執(zhí)行邏輯中的日志打印輸出。如果是平常業(yè)務邏輯，抽象觀察者定義的入參是具有業(yè)務意義的，大家可以類比項目上使用到的  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("被觀察者狀態(tài)改變, 通知所有已注冊觀察者");     } }

觀察者模式結合業(yè)務

因為公司業(yè)務場景保密，所以下面我們通過【新警察故事】的電影情節(jié)，稍微篡改下劇情，模擬出我們的觀察者模式應用場景

假設：目前我們有三個警察，分別是龍哥、鋒哥、老三，他們受命跟進犯罪嫌疑人阿祖。如果發(fā)現(xiàn)犯罪嫌疑人阿祖有動靜，龍哥、峰哥負責實施抓捕行動，老三向警察局搖人，流程圖如下：

如果說使用常規(guī)代碼寫這套流程，是能夠實現(xiàn)需求的，一把梭的邏輯可以實現(xiàn)一切需求。但是，如果說下次行動，龍哥讓老三跟著自己實施抓捕，亦或者說龍哥團隊擴張，來了老四、老五、老六...

對比觀察者模式角色定義，老四、老五、老六都是具體的觀察者(Concrete Observer)

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術社區(qū)

2. 首當其沖，增加了代碼的復雜性。實現(xiàn)類或者說這個方法函數奇大無比，因為隨著警員的擴張，代碼塊會越來越大

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

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

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

這里使用 Java SpringBoot 項目結構來書寫觀察者模式，代碼最終推送到 Github  倉庫。讀者可以先把倉庫拉下來，因為其中不止示例代碼，還包括 Guava 和 Spring 的觀察者模式實現(xiàn) GitHub 倉庫地址

首先，定義觀察者模式中的觀察者角色，分別為抽象觀察者接口以及三個具體觀察者實現(xiàn)類。實際業(yè)務中，設計模式會和 Spring 框架相結合，所以示例代碼中包含  Spring 相關注解及接口

其次，定義抽象被觀察者接口以及具體被觀察者實現(xiàn)類。同上，被觀察者也需要成為 Spring Bean，托管于 IOC 容器管理

到這里，一個完整的觀察者模式就完成了。但是，細心的讀者會發(fā)現(xiàn)這樣的觀察者模式會有一個小問題，這里先不說明，繼續(xù)往下看。接下來就需要實際操練一番，注冊這些觀察者，通過被觀察者觸發(fā)事件來通知觀察者

如何實現(xiàn)開閉原則

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

其實非常簡單，平常 Web 項目基本都會使用 Spring 框架開發(fā)，那自然是要運用其中的特性解決場景問題。我們這里通過  改造具體被觀察者實現(xiàn)開閉原則

如果看過之前作者寫過的設計模式文章，對 InitializingBean 接口不會感到陌生，我們在 afterPropertiesSet  方法中，通過注入的 IOC 容器獲取到所有觀察者對象 并添加至被觀察者通知容器中。這樣的話，觸發(fā)觀察者事件，代碼中只需要一行即可完成通知

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

后續(xù)如果再有新的觀察者類添加，只需要創(chuàng)建新的類實現(xiàn)抽象觀察者接口即可完成需求。有時候，能夠被封裝起來的不止是 DateUtil  類型的工具類，一些設計模式也可以被封裝，繼而更好的服務開發(fā)者靈活運用。這里會分別介紹 Guava#EventBus 以及 Spring#事件模型

同步異步的概念

在介紹 EventBus 和 Spring  事件模型之前，有一道繞不過去的彎，那就是同步執(zhí)行、異步執(zhí)行的概念，以及在什么樣的場景下使用同步、異步模型?

• 同步執(zhí)行：所謂同步執(zhí)行，指的就是在發(fā)出一個請求后，在沒有獲得調用結果之前，調用者就會等待在當前代碼。直到獲取到調用方法的執(zhí)行結果，才算是結束。總結一句話就是  由調用者主動等待這個調用的結果，未返回之前不執(zhí)行別的操作

• 異步執(zhí)行：而異步執(zhí)行恰恰相反，發(fā)出調用請求后立即返回，并向下執(zhí)行代碼。異步調用方法一般不會有返回結果，調用之后就可以執(zhí)行別的操作，一般通過回調函數的方式通知調用者結果

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

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

Guava EventBus 解析

EventBus 是 Google Guava 提供的消息發(fā)布-訂閱類庫，是設計模式中的觀察者模式(生產/消費者模型)的經典實現(xiàn)

具體代碼已上傳 GitHub 代碼倉庫，EventBus 實現(xiàn)中包含同步、異步兩種方式，代碼庫中由同步方式實現(xiàn)觀察者模式

因為 EventBus 并不是文章重點，所以這里只會對其原理進行探討。首先 EventBus 是一個同步類庫，如果需要使用異步的，那就創(chuàng)建時候指定  AsyncEventBus

// 創(chuàng)建同步 EventBus EventBus eventBus = new EventBus();  // 創(chuàng)建異步 AsyncEventBus EventBus eventBus = new AsyncEventBus(Executors.newFixedThreadPool(10));

注意一點，創(chuàng)建 AsyncEventBus 需要指定線程池，其內部并沒有默認指定。當然也別像上面代碼直接用 Executors  創(chuàng)建，作者是為了圖省事，如果從規(guī)范而言，還是消停的使用默認線程池構建方法創(chuàng)建 new ThreadPoolExecutor(xxx);

EventBus 同步實現(xiàn)有一個比較有意思的點。觀察者操作同步、異步行為時，均使用 Executor 去執(zhí)行觀察者內部代碼，那如何保證 Executor  能同步執(zhí)行呢。Guava 是這么做的：實現(xiàn) Executor 接口，重寫執(zhí)行方法，調用 run 方法

enum DirectExecutor implements Executor {     INSTANCE;      @Override     public void execute(Runnable command) {         command.run();     } }

大家有興趣可以去看下 EventBus 源碼，不是很難理解，工作使用上還是挺方便的。只不過也有不好的地方，因為 EventBus  屬于進程內操作，如果使用異步 AsyncEventBus 執(zhí)行業(yè)務，存在丟失任務的可能

Spring 事件模型

Spring 大拿設計的觀察者模式抽象是作者看到的最優(yōu)雅、最功能的設計，如果想要玩耍觀察者模式推薦指數 ??????????

如果想要使用 ApplicationEvent 玩轉觀察者模式，只需要簡單幾步?？偨Y：操作簡單，功能強大

創(chuàng)建業(yè)務相關的 MyEvent，需要繼承 ApplicationEvent，重寫有參構造函數

定義不同的監(jiān)聽器(觀察者)比如 ListenerOne 實現(xiàn) ApplicationListener接口，重寫  onApplicationEvent 方法

通過 ApplicationContext#publishEvent 方法發(fā)布具體事件

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

Spring 事件同樣支持異步編程，需要在具體 Listener 實現(xiàn)類上添加 @Async 注解。支持 Listener 訂閱的順序，比如說有  A、B、C 三個 Listener。可以通過 @Order 注解實現(xiàn)多個觀察者順序消費

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

到此，相信大家對“Guava和Spring怎么抽象觀察者模式”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！