可能你聽過,但不一定這樣用過
哈嘍,大家好,我是指北君。
今天我們繼續(xù)看看Guava,比較好用的事件驅(qū)動工具EventBus
Guava EventBus
EventBus是Guava的事件處理機制,是設計模式中觀察者模式(生產(chǎn)/消費者編程模型)的優(yōu)雅實現(xiàn)。對于事件監(jiān)聽和發(fā)布訂閱模式,EventBus使用非常簡單便捷。
如果你做過CS的開發(fā),下面這段代碼可能會比較熟悉。
為按鈕注冊事件監(jiān)聽,當按鈕被點擊時,則觸發(fā)監(jiān)聽中相應的回調(diào)。在上面的代碼中,有三個角色事件(Event),事件源(Button),監(jiān)聽(Listener),按鈕作為事件源,當點擊行為觸發(fā)時,會將該行為封裝成對應的點擊事件,并根據(jù)行為類型將事件傳遞到響應的監(jiān)聽器上, 這也就是我們常說的監(jiān)聽器模式。
使用場景
實現(xiàn)消息生產(chǎn)者與消費者間的解耦,對應事件源與監(jiān)聽器,而消息則是事件
通過事件驅(qū)動業(yè)務流程扭轉(zhuǎn),通過異步執(zhí)行機制實現(xiàn)代碼非阻塞執(zhí)行
擴展主線外的分支業(yè)務,減少代碼的侵入,比如各個環(huán)節(jié)的消息通知、短信提醒等
實現(xiàn)消息廣播到不同的模塊中
示例
訂單支付時的消息發(fā)送
測試: 我們可以定義各種事件,比如訂單創(chuàng)建、訂單取消、訂單支付... 只需要簡單的三個步驟即可:
同時我們可以通過AsyncEventBus建立事件異步總線,這樣在事件被觸發(fā)時,可以異步通知監(jiān)聽者完成事件回調(diào),以此來提高響應速度。
核心
- EventBus
事件總線,可以理解為事件與監(jiān)聽器的上下文,主要實現(xiàn)事件的注冊、事件的分發(fā)、以及監(jiān)聽器的回調(diào),主要提供的方法包括:
register 注冊監(jiān)聽,將監(jiān)聽器注冊到事件總線,通過注解@Subscribe通知其監(jiān)聽的事件類型(第一個方法參數(shù)類型)
unregister 卸載監(jiān)聽,從事件總線移除監(jiān)聽
post 發(fā)送事件通知,根據(jù)post事件類型,找到所有訂閱了該類型事件的監(jiān)聽器,并將事件推送到監(jiān)聽器對應的監(jiān)聽方法
- Subscribe
通過@Subscribe標識監(jiān)聽器所關注的事件類型
- Event
可以是任何對象,當然不建議將基礎類型或String作為事件類型,這樣就沒法做到按類型區(qū)分了
通過上面的圖就可以很清楚各個各個組件的職責,以及如何通過事件總線完成事件向監(jiān)聽的傳播,最終基于事件回調(diào)機制完成消息傳遞。基于事件驅(qū)動的服務模型
上面這種結(jié)構(gòu)的圖形是不是在很多位置都見過,這是一種經(jīng)典的設計模式。試想一下,我們不通過事件驅(qū)動行為時,一般你們怎么寫代碼,通過ifelse?或者其他有著異曲同工的 實現(xiàn)方法,目的最后都是一樣?;贕uava提供的工具,我們不僅在使用時只需要簡單的三個步驟就能實現(xiàn),同樣,當需要屏蔽該功能時只需要去掉register一行即可,對整體功能 也沒有任何的影響。
在我們引入某種設計模式,某種架構(gòu)模型時,總的目的都是為了降低代碼模塊間的耦合度,提升代碼整體的可讀性,最終讓代碼能夠易于維護性,或者有一定的復用性。
總結(jié)
不僅能夠使消息的發(fā)起者與接收者之間進行解耦,最主要的是通過消息傳遞渠道實現(xiàn)消息異步傳播,提升系統(tǒng)效率