[[390106]]

 本文轉(zhuǎn)載自微信公眾號(hào)「源碼興趣圈」，作者龍臺(tái)。轉(zhuǎn)載本文請(qǐng)聯(lián)系源碼興趣圈公眾號(hào)。   

今天講解一篇行為型設(shè)計(jì)模式，什么是行為型?行為型主要負(fù)責(zé)設(shè)計(jì) 類(lèi)或?qū)ο笾g的交互。工作中常用的觀察者模式就是一種行為型設(shè)計(jì)模式

最近在嘗試重構(gòu)之前寫(xiě)過(guò)的代碼。在重新梳理過(guò)業(yè)務(wù)之后，發(fā)現(xiàn)已有的設(shè)計(jì)場(chǎng)景應(yīng)該能夠接入到設(shè)計(jì)模式，而且查看了代碼的提交記錄，更是堅(jiān)定了此想法

保持之前的一貫作風(fēng)，想要說(shuō)明一個(gè)設(shè)計(jì)模式，需要三板斧支撐。什么是觀察者模式?如何使用觀察者模式?項(xiàng)目中應(yīng)該如何應(yīng)用?

觀察者設(shè)計(jì)模式大綱如下：

1. 什么是觀察者模式
2. 觀察者模式代碼如何寫(xiě)
3. 如何使用觀察者模式結(jié)合業(yè)務(wù)
4. Guava EventBus 觀察者模式
5. Spring ApplicationEvent 事件模型
6. 觀察者模式最后的總結(jié)

什么是觀察者模式

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

其實(shí)我個(gè)人而言，不太喜歡使用文字去定義一種設(shè)計(jì)模式的語(yǔ)義，因?yàn)檫@樣總是難以理解。所以就有了下面生活中的例子，來(lái)幫助讀者更好的去理解模式的語(yǔ)義。類(lèi)圖如下所示：

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

• 主題(被觀察者)(Subject)：抽象主題角色把所有觀察者對(duì)象保存在一個(gè)容器里，提供添加和移除觀察者接口，并且提供出通知所有觀察者對(duì)象接口(也有作者通過(guò) Observable 描述)
• 具體主題(具體被觀察者)(Concrete Subject)：具體主題角色的職責(zé)就是實(shí)現(xiàn)抽象目標(biāo)角色的接口語(yǔ)義，在被觀察者狀態(tài)更改時(shí)，給容器內(nèi)所有注冊(cè)觀察者發(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)：抽象觀察者角色是觀察者的行為抽象，它定義了一個(gè)修改接口，當(dāng)被觀察者發(fā)出事件時(shí)通知自己
• 具體觀察者(Concrete Observer)：實(shí)現(xiàn)抽象觀察者定義的更新接口，可以在被觀察者發(fā)出事件時(shí)通知自己

public interface Observer { 
    void update(String message);  // String 入?yún)⒅皇桥e例, 真實(shí)業(yè)務(wù)不會(huì)限制 
} 
 
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"); 
    } 
} 

我們跑一下上面的觀察者模式示例，如果不出意外的話會(huì)將兩個(gè)觀察者執(zhí)行邏輯中的日志打印輸出。如果是平常業(yè)務(wù)邏輯，抽象觀察者定義的入?yún)⑹蔷哂袠I(yè)務(wù)意義的，大家可以類(lèi)比項(xiàng)目上使用到的 MQ Message 機(jī)制

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)改變, 通知所有已注冊(cè)觀察者"); 
    } 
} 

觀察者模式結(jié)合業(yè)務(wù)

因?yàn)楣緲I(yè)務(wù)場(chǎng)景保密，所以下面我們通過(guò)【新警察故事】的電影情節(jié)，稍微篡改下劇情，模擬出我們的觀察者模式應(yīng)用場(chǎng)景

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

如果說(shuō)使用常規(guī)代碼寫(xiě)這套流程，是能夠?qū)崿F(xiàn)需求的，一把梭的邏輯可以實(shí)現(xiàn)一切需求。但是，如果說(shuō)下次行動(dòng)，龍哥讓老三跟著自己實(shí)施抓捕，亦或者說(shuō)龍哥團(tuán)隊(duì)擴(kuò)張，來(lái)了老四、老五、老六...

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

如果按照上面的設(shè)想，我們通過(guò)“一把梭”的方式把代碼寫(xiě)出來(lái)會(huì)有什么問(wèn)題呢?如下：

1. 首當(dāng)其沖，增加了代碼的復(fù)雜性。實(shí)現(xiàn)類(lèi)或者說(shuō)這個(gè)方法函數(shù)奇大無(wú)比，因?yàn)殡S著警員的擴(kuò)張，代碼塊會(huì)越來(lái)越大
2. 違背了開(kāi)閉原則，因?yàn)闀?huì)頻繁改動(dòng)不同警員的任務(wù)。每個(gè)警員的任務(wù)不是一成不變的，舉個(gè)例子來(lái)說(shuō)這次針對(duì)疑犯，讓峰哥實(shí)施的抓捕行動(dòng)，下次就可能是疏散民眾，難道每次的更改都需要改動(dòng)“一把梭”的代碼

第一種我們可以通過(guò)，大函數(shù)拆小函數(shù) 或者 大類(lèi)拆分為小類(lèi) 的方式解決代碼負(fù)責(zé)性問(wèn)題。但是，開(kāi)閉原則卻不能避免掉，因?yàn)殡S著警員(觀察者)的增多及減少，勢(shì)必會(huì)面臨頻繁改動(dòng)原函數(shù)的情況

當(dāng)我們面對(duì)這種 已知會(huì)變動(dòng)，并且可能會(huì) 頻繁變動(dòng)不固定 的代碼，就要使用抽象思維來(lái)進(jìn)行設(shè)計(jì)，進(jìn)而保持代碼的簡(jiǎn)潔、可維護(hù)

這里使用 Java SpringBoot 項(xiàng)目結(jié)構(gòu)來(lái)書(shū)寫(xiě)觀察者模式，代碼最終推送到 Github 倉(cāng)庫(kù)。讀者可以先把倉(cāng)庫(kù)拉下來(lái)，因?yàn)槠渲胁恢故纠a，還包括 Guava 和 Spring 的觀察者模式實(shí)現(xiàn) GitHub 倉(cāng)庫(kù)地址

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

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

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

如何實(shí)現(xiàn)開(kāi)閉原則

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

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

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

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

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

同步異步的概念

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

• 同步執(zhí)行：所謂同步執(zhí)行，指的就是在發(fā)出一個(gè)請(qǐng)求后，在沒(méi)有獲得調(diào)用結(jié)果之前，調(diào)用者就會(huì)等待在當(dāng)前代碼。直到獲取到調(diào)用方法的執(zhí)行結(jié)果，才算是結(jié)束。總結(jié)一句話就是 由調(diào)用者主動(dòng)等待這個(gè)調(diào)用的結(jié)果，未返回之前不執(zhí)行別的操作
• 異步執(zhí)行：而異步執(zhí)行恰恰相反，發(fā)出調(diào)用請(qǐng)求后立即返回，并向下執(zhí)行代碼。異步調(diào)用方法一般不會(huì)有返回結(jié)果，調(diào)用之后就可以執(zhí)行別的操作，一般通過(guò)回調(diào)函數(shù)的方式通知調(diào)用者結(jié)果

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

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

Guava EventBus 解析

EventBus 是 Google Guava 提供的消息發(fā)布-訂閱類(lèi)庫(kù)，是設(shè)計(jì)模式中的觀察者模式(生產(chǎn)/消費(fèi)者模型)的經(jīng)典實(shí)現(xiàn)

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

因?yàn)?EventBus 并不是文章重點(diǎn)，所以這里只會(huì)對(duì)其原理進(jìn)行探討。首先 EventBus 是一個(gè)同步類(lèi)庫(kù)，如果需要使用異步的，那就創(chuàng)建時(shí)候指定 AsyncEventBus

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

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

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

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

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

Spring 事件模型

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

如果想要使用 ApplicationEvent 玩轉(zhuǎn)觀察者模式，只需要簡(jiǎn)單幾步。總結(jié)：操作簡(jiǎn)單，功能強(qiáng)大

創(chuàng)建業(yè)務(wù)相關(guān)的 MyEvent，需要繼承 ApplicationEvent，重寫(xiě)有參構(gòu)造函數(shù)

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

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

Spring 事件與 Guava EventBus 一樣，代碼就不粘貼了，都已經(jīng)存放到 Github 代碼倉(cāng)庫(kù)。這里重點(diǎn)介紹下 Spring 事件模型的特點(diǎn)，以及使用事項(xiàng)

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

作者建議讀者朋友一定要跑下 ApplicationEvent 的 Demo，在使用框架的同時(shí)也 要合理的運(yùn)用框架提供的工具輪子，因?yàn)楸豢蚣芊庋b出的功能，一般而言要比自己寫(xiě)的功能更強(qiáng)大、出現(xiàn)問(wèn)題的幾率更少。同時(shí)，切記不要造重復(fù)輪子，除非功能點(diǎn)不滿足的情況下，可以借鑒原有輪子的基礎(chǔ)上開(kāi)發(fā)自己功能

結(jié)言

文章通過(guò)圖文并茂的方式幫助大家梳理了下觀察者模式的實(shí)現(xiàn)方式，更是推出了進(jìn)階版的 EventBus 以及 ApplicationEvent，相信大家看完之后可以很愉快的在自己項(xiàng)目中玩耍設(shè)計(jì)模式了。切記哈，要在合理的場(chǎng)景下使用模式，一般而言觀察者模式作用于 觀察者與被觀察者之間的解耦合

最后解答下最早提到的問(wèn)題，項(xiàng)目中的觀察者模式 應(yīng)該使用同步模型還是異步模型呢

如果只是使用觀察者模式拆分代碼使其滿足 開(kāi)閉原則、高內(nèi)聚低耦合、職責(zé)單一 等特性，那么自然是使用同步去做，因?yàn)檫@種方式是最為穩(wěn)妥。而如果 不關(guān)心觀察者執(zhí)行結(jié)果或者考慮性能 等情況，則可以使用異步的方式，通過(guò)回調(diào)的方式滿足業(yè)務(wù)返回需求

關(guān)于觀察者設(shè)計(jì)模式本文就講到這里，后面會(huì)陸續(xù)輸出工廠、原型、享元等模式;如果文章對(duì)你有幫助那就點(diǎn)個(gè)關(guān)注支持下吧，祝好。