前言
試想這樣一個問題,當某個事件發生時,比如在游戲中A模塊修改了用戶的金幣數,而B模塊和C模塊提供的功能都依賴于用戶的金幣數,那么,A模塊在修改金幣數的同時,就需要通知B模塊和C模塊,常規的方法就是A模塊持有B模塊和C模塊的物件,然后分別通過呼叫物件介面的方式告訴它們,“嘿,我修改了用戶的金幣數,改成了10金幣”,
但這樣就帶來了許多問題:
- A模塊參考了B模塊和C模塊,耦合嚴重
- A模塊修改金幣數的方法中呼叫了B,C模塊的方法,當這兩個模塊發生變化時(比如B模塊接收金幣數的介面名稱改變了,或是C模塊不再需要知道金幣數改變了),A模塊也要修改
- 當又出現一個D模塊也需要知道金幣數的變化時,同樣需要修改A模塊以適應這種需求
為了解決上面的問題,我們自然想到了觀察者模式,
觀察者模式
這里簡單說一下什么是觀察者模式:定義物件之間的一對多依賴,這樣一來,當一個物件改變狀態時,它的所有依賴者(稱之為觀察者)都會接收到通知并自動更新,
觀察者模式的好處是,物件之間是松耦合的,當一個物件改變狀態時,它并不需要知道自己的觀察者是誰,只需要發布通知即可,任何時候都可以增加或洗掉觀察者,不會影響到發布通知的物件,
而事件分發系統就是觀察者模式的一個具體實作
事件分發系統
事件分發系統核心需要提供的功能主要包括以下幾個部分:
- 當一個物件發生改變時,可以認為此時產生了一個事件,提供一個派發事件的介面,以通知所有的觀察者
- 需要提供注冊監聽事件的介面,以讓觀察者可以訂閱自己需要接收的事件
- 還需提供反注冊監聽事件介面,以讓觀察者可以取消自己的訂閱
- 最好還能在訂閱的時候設定優先級,優先級越高的可以越先被通知
使用事件分發系統解決問題
首先,來看看使用事件分發系統處理上面提到的問題,會是什么樣的效果,
A模塊只需要派發金幣修改事件,B,C模塊只需要訂閱金幣修改事件,之后便可以收到通知了,是不是很簡單呢
local B = class()
function B:on_money_change( money )
print(money, "B receive event")
end
-- 訂閱金幣修改事件
EventSystem:on(Event.MoneyChanged, B.on_money_change, {target = B})
local C = class()
function C:on_money_change( money )
print(money, "C receive event")
end
EventSystem:on(Event.MoneyChanged, C.on_money_change, {target = C})
-- 在A模塊中派發金幣修改事件,當前金幣為10
EventSystem:emit(Event.MoneyChanged, 10)
接下來會仔細解讀一下這個EventSystem事件分發系統的Lua實作代碼,
實作事件分發系統時,需要小心一些特殊情況,比如有以下幾個坑,讀者可以留意一下代碼中對這幾個坑的處理
- 在事件派發的程序中訂閱該事件,訂閱還有優先級,需要小心處理排序問題
- 在事件派發的程序中取消訂閱該事件,需要采用標記移除,不能直接移除
- 在事件派發的程序中又派發了該事件,如何確定事件派發完成
為了便于講解,下面的代碼省略了一些非關鍵性的代碼,用--- ...代替,
注冊監聽事件介面
function EventSystem:on( event, func, params )
--- ...
local event_listener = self._listeners[event]
params = params or {}
local priority = params.priority or 0
local target = params.target
--- ...
local cb = {target = target, func = func, id = id, priority = priority}
table.insert(event_listener.list, cb)
id = id + 1
if priority > 0 then
event_listener.need_sort = true
self:sort(event_listener)
end
end
on方法中event引數表示要注冊監聽的事件名稱,func引數表示當事件發生時要觸發的回呼函式,params表示額外引數,可以設定注冊監聽的目標target(可以利用它反注冊所有與其相關的監聽),也可以設定要注冊監聽的優先級,優先級越高的越先執行
on方法的實作還是比較簡單的,主要就是將注冊的相關資訊插入到event_listener表中,但是明明注冊的監聽是有優先級的,卻仍然只是呼叫table.insert將資訊插入到表的末尾,這是為什么呢?讀者可以先留意一下,后面會有詳細解釋,
還需要格外注意的是sort方法
function EventSystem:sort( listener )
if listener.need_sort == true and listener.emit_count == 0 then
table.sort(listener.list, function ( a, b )
if a.priority == b.priority then
return a.id < b.id
else
return a.priority > b.priority
end
end)
listener.need_sort = false;
end
end
可以看到sort方法必須在listener.emit_count == 0時才會進行排序,listener.emit_count == 0表示的是當前的事件沒有處于派發狀態,后面講到派發介面時會詳細解釋,這里讀者只需要知道其表示的含義即可,
事件處于派發狀態時不能進行優先級排序原因是可能會造成回呼的重復觸發,
比如當前事件有4個回呼 a, b, c, d,派發事件是順序執行回呼,當執行到第3個回呼c時
如果在c回呼中又注冊了一個優先級最高的回呼e,立刻排序的話,e插入到第一位,c會被擠到第4位,順序執行到第4個回呼時,導致c又被呼叫一次
反注冊事件監聽介面
function EventSystem:off( event, func, params )
--- ...
local event_listener = self._listeners[event]
params = params or {}
for i,cb in ipairs(event_listener.list) do
if cb.func == func and cb.target == params.target then
if event_listener.emit_count > 0 then
-- 派發程序中只進行標記洗掉
cb.need_remove = true
event_listener.need_clean = true
else
table.remove(event_listener.list, i)
end
break;
end
end
end
off方法用于取消事件監聽,當事件未處于派發程序中時,直接呼叫table.remove移除注冊資訊即可,但當事件處于派發程序中時,不能直接移除,只能先進行標記
在事件處于派發程序中時不能直接移除的原因是可能導致遺漏觸發某些回呼
比如當前事件有5個回呼 a, b, c, d, e,順序執行到第3個回呼c時
如果在c回呼中呼叫了off方法取消自己的監聽,此時直接移除c的話,會導致d回呼移動到第3位,e移動到第4位,順序執行到第4個回呼時,呼叫的是e而遺漏了d
事件派發介面
function EventSystem:emit( event, ... )
--- ...
local event_listener = self._listeners[event]
local interrupt = false
local length = #event_listener.list
-- 這里不能使用ipairs,確保不會觸發在派發程序中注冊的事件
-- 只取當前已經注冊的事件數量,如果在派發程序中再注冊(呼叫了table.insert),本次派發也不會呼叫
for i = 1, length do
if interrupt == true then
break
end
local cb = event_listener.list[i]
if cb.func and cb.need_remove ~= true then
event_listener.emit_count = event_listener.emit_count + 1
if cb.target then
interrupt = cb.func(cb.target, ...)
else
interrupt = cb.func(...)
end
event_listener.emit_count = event_listener.emit_count - 1
end
end
self:sort(event_listener);
self:clean(event_listener);
return interrupt
end
emit方法負責派發一個事件,順序執行event_listener中注冊的回呼,事件的派發支持中斷,當執行某個回呼時,如果這個回呼回傳了true則可以中斷當前事件的派發,
值得一提的是,代碼通過對應的event_listener.emit_count = event_listener.emit_count + 1和event_listener.emit_count = event_listener.emit_count - 1來記錄事件的派發狀態,當emit_count > 0則表明事件還在派發程序中,當emit_count == 0則表明事件派發完成,
不能使用event_listener.is_emiting = true和event_listener.is_emiting = false代替的原因是如果在觸發的回呼中又派發了事件,形成了遞回,那么二次派發事件結束時會直接將event_listener.is_emiting置為flase,導致一次派發事件對應的派發狀態被標記錯誤
更多
事件分發系統的完整原始碼可以點擊這里查看,測驗用例可以點擊這里查看
更多Lua相關的設計與使用,比如面向物件(代碼中用到的class關鍵字),組件系統,分模塊加載等等,可以查看GitHub倉庫LuaKit
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/16304.html
標籤:設計模式
上一篇:圖解Java設計模式之解釋器模式
