前言

设计模式不论是在面试还是工作中都会遇到，但我常常碰到小伙伴埋怨理论工作中本人利用设计模式的机会十分小。

正好最近工作中遇到一个用 观察者模式 解决问题的场景，和大家一起分享。

背景如下：

在用户创立完订单的规范流程中须要做额定一些事件：

同时这些业务也是不固定的，随时会依据业务倒退减少、批改逻辑。

如果间接将逻辑写在下单业务中，这一 ”坨“ 不是很外围的业务就会占据的越来越多，批改时还有可能影响到失常的下单流程。

当然也有其余计划，比方能够启动几个定时工作，定期扫描扫描订单而后实现本人的业务逻辑；但这样会节约许多不必要的申请。

观察者模式

因而观察者模式就应运而生，它是由事件发布者在本身状态发生变化时发出通知，由观察者获取音讯实现业务逻辑。

这样事件发布者和接收者就能够齐全解耦，互不影响；实质上也是对开闭准则的一种实现。

示例代码

先大体看一下观察者模式所应用到的接口与关系：

• 主体接口：定义了注册实现、循环告诉接口。
• 观察者接口：定义了接管主体告诉的接口。
• 主体、观察者接口都能够有多个实现。
• 业务代码只须要应用 Subject.Nofity() 接口即可。

接下来看看创立订单过程中的实现案例。

代码采纳 go 实现，其余语言也是相似。

首先依照上图定义了两个接口：

type Subject interface {Register(Observer)
    Notify(data interface{})
}

type Observer interface {Update(data interface{})
}

因为咱们这是一个下单的事件，所以定义了 OrderCreateSubject 实现 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 切片是用于寄存所有订阅了下单事件的观察者。

接着便是编写观察者业务逻辑了，这里我实现了两个：

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 

1. 创立一个 创立订单 的主体 subject。
2. 注册所有的订阅事件。
3. 在须要告诉处调用 Notify 办法。

这样一旦咱们须要批改各个事件的实现时就不会相互影响，即使是要退出其余实现也是非常容易的：

1. 编写实现类。
2. 注册进实体。

不会再批改外围流程。

配合容器

其实咱们也能够省略掉注册事件的步骤，那就是应用容器；大抵流程如下：

1. 自定义的事件全副注入进容器。
2. 再注册事件的中央从容器中取出所有的事件，挨个注册。

这里所应用的容器是 https://github.com/uber-go/dig

批改后的代码中，每当咱们新增一个观察者（事件订阅）时，只须要应用容器所提供 Provide 函数注册进容器即可。

同时为了让容器可能反对同一个对象存在多个实例也须要新增局部代码：

Observer.go:

type Observer interface {Update(data interface{})
}
type (
    Instance struct {
        dig.Out
        Instance Observer `group:"observers"`
    }

    InstanceParams struct {
        dig.In
        Instances []Observer `group:"observers"`}
)

在 observer 接口中须要新增两个构造体用于寄存同一个接口的多个实例。

group:"observers" 用于申明是同一个接口。

创立具体观察者对象时返回 Instance 对象。

func NewB1() Instance {
    return Instance{Instance: &B1CreateOrder{},
    }
}

func NewB2() Instance {
    return Instance{Instance: &B2CreateOrder{},
    }
}

其实就是用 Instance 包装了一次。

这样在注册观察者时，便能从 InstanceParams.Instances 中取出所有的观察者对象了。

    err = c.Invoke(func(subject Subject, params InstanceParams) {
        for _, instance := range params.Instances {subject.Register(instance)
        }
    })

这样在应用时间接从容器中获取主题对象，而后告诉即可：

    err = c.Invoke(func(subject Subject) {subject.Notify("abc123")
    })

更多对于 dig 的用法能够参考官网文档：

https://pkg.go.dev/go.uber.org/dig#hdr-Value_Groups

总结

有教训的开发者会发现和公布订阅模式十分相似，当然他们的思路是相似的；咱们不必纠结与两者的差别（面试时除外）；学会其中的思路更加重要。