觀察者模式的實(shí)際應(yīng)用
本文轉(zhuǎn)載自微信公眾號「crossoverJie」，作者crossoverJie。轉(zhuǎn)載本文請聯(lián)系crossoverJie公眾號。
前言
設(shè)計(jì)模式不管是在面試還是工作中都會(huì)遇到，但我經(jīng)常碰到小伙伴抱怨實(shí)際工作中自己應(yīng)用設(shè)計(jì)模式的機(jī)會(huì)非常小。
正好最近工作中遇到一個(gè)用觀察者模式解決問題的場景，和大家一起分享。
背景如下：
在用戶創(chuàng)建完訂單的標(biāo)準(zhǔn)流程中需要做額外一些事情：
同時(shí)這些業(yè)務(wù)也是不固定的，隨時(shí)會(huì)根據(jù)業(yè)務(wù)發(fā)展增加、修改邏輯。
如果直接將邏輯寫在下單業(yè)務(wù)中，這一”坨“不是很核心的業(yè)務(wù)就會(huì)占據(jù)的越來越多，修改時(shí)還有可能影響到正常的下單流程。
當(dāng)然也有其他方案，比如可以啟動(dòng)幾個(gè)定時(shí)任務(wù)，定期掃描掃描訂單然后實(shí)現(xiàn)自己的業(yè)務(wù)邏輯;但這樣會(huì)浪費(fèi)許多不必要的請求。
觀察者模式
因此觀察者模式就應(yīng)運(yùn)而生，它是由事件發(fā)布者在自身狀態(tài)發(fā)生變化時(shí)發(fā)出通知，由觀察者獲取消息實(shí)現(xiàn)業(yè)務(wù)邏輯。
這樣事件發(fā)布者和接收者就可以完全解耦，互不影響;本質(zhì)上也是對開閉原則的一種實(shí)現(xiàn)。
示例代碼
先大體看一下觀察者模式所使用到的接口與關(guān)系：
- 主體接口：定義了注冊實(shí)現(xiàn)、循環(huán)通知接口。
- 觀察者接口：定義了接收主體通知的接口。
- 主體、觀察者接口都可以有多個(gè)實(shí)現(xiàn)。
- 業(yè)務(wù)代碼只需要使用 Subject.Nofity() 接口即可。
接下來看看創(chuàng)建訂單過程中的實(shí)現(xiàn)案例。
代碼采用 go 實(shí)現(xiàn)，其他語言也是類似。
首先按照上圖定義了兩個(gè)接口：
- type Subject interface {
- Register(Observer)
- Notify(data interface{})
- }
- type Observer interface {
- Update(data interface{})
- }
由于我們這是一個(gè)下單的事件，所以定義了 OrderCreateSubject 實(shí)現(xiàn) Subject：
- type OrderCreateSubject struct {
- observerList []Observer
- }
- func NewOrderCreate() Subject {
- return &OrderCreateSubject{}
- }
- func (o *OrderCreateSubject) Register(observer Observer) {
- o.observerList = append(o.observerList, observer)
- }
- func (o *OrderCreateSubject) Notify(data interface{}) {
- for _, observer := range o.observerList {
- observer.Update(data)
- }
- }
其中的 observerList 切片是用于存放所有訂閱了下單事件的觀察者。
接著便是編寫觀察者業(yè)務(wù)邏輯了，這里我實(shí)現(xiàn)了兩個(gè)：
- type B1CreateOrder struct {
- }
- func (b *B1CreateOrder) Update(data interface{}) {
- fmt.Printf("b1.....data %v \n", data)
- }
- type B2CreateOrder struct {
- }
- func (b *B2CreateOrder) Update(data interface{}) {
- fmt.Printf("b2.....data %v \n", data)
- }
使用起來也非常簡單：
- func TestObserver(t *testing.T) {
- create := NewOrderCreate()
- create.Register(&B1CreateOrder{})
- create.Register(&B2CreateOrder{})
- create.Notify("abc123")
- }
Output：
- b1.....data abc123
- b2.....data abc123
- 創(chuàng)建一個(gè)創(chuàng)建訂單的主體 subject。
- 注冊所有的訂閱事件。
- 在需要通知處調(diào)用 Notify 方法。
這樣一旦我們需要修改各個(gè)事件的實(shí)現(xiàn)時(shí)就不會(huì)互相影響，即便是要加入其他實(shí)現(xiàn)也是非常容易的：
- 編寫實(shí)現(xiàn)類。
- 注冊進(jìn)實(shí)體。
不會(huì)再修改核心流程。
配合容器
其實(shí)我們也可以省略掉注冊事件的步驟，那就是使用容器;大致流程如下：
自定義的事件全部注入進(jìn)容器。
再注冊事件的地方從容器中取出所有的事件，挨個(gè)注冊。
這里所使用的容器是 https://github.com/uber-go/dig
修改后的代碼中，每當(dāng)我們新增一個(gè)觀察者(事件訂閱)時(shí)，只需要使用容器所提供 Provide 函數(shù)注冊進(jìn)容器即可。
同時(shí)為了讓容器能夠支持同一個(gè)對象存在多個(gè)實(shí)例也需要新增部分代碼：
- type Observer interface {
- Update(data interface{})
- }
- type (
- Instance struct {
- dig.Out
- Instance Observer `group:"observers"`
- }
- InstanceParams struct {
- dig.In
- Instances []Observer `group:"observers"`
- }
- )
在 observer 接口中需要新增兩個(gè)結(jié)構(gòu)體用于存放同一個(gè)接口的多個(gè)實(shí)例。
group:"observers" 用于聲明是同一個(gè)接口。
創(chuàng)建具體觀察者對象時(shí)返回 Instance 對象。
- func NewB1() Instance {
- return Instance{
- Instance: &B1CreateOrder{},
- }
- }
- func NewB2() Instance {
- return Instance{
- Instance: &B2CreateOrder{},
- }
- }
其實(shí)就是用 Instance 包裝了一次。
這樣在注冊觀察者時(shí)，便能從 InstanceParams.Instances 中取出所有的觀察者對象了。
- err = c.Invoke(func(subject Subject, params InstanceParams) {
- for _, instance := range params.Instances {
- subject.Register(instance)
- }
- })
這樣在使用時(shí)直接從容器中獲取主題對象，然后通知即可：
- err = c.Invoke(func(subject Subject) {
- subject.Notify("abc123")
- })
更多關(guān)于 dig 的用法可以參考官方文檔：
https://pkg.go.dev/go.uber.org/dig#hdr-Value_Groups
總結(jié)
有經(jīng)驗(yàn)的開發(fā)者會(huì)發(fā)現(xiàn)和發(fā)布訂閱模式非常類似，當(dāng)然他們的思路是類似的;我們不用糾結(jié)與兩者的差異(面試時(shí)除外);學(xué)會(huì)其中的思路更加重要。
