Golang中的观察者模式：优化订单处理系统
当涉及到订单处理系统时，观察者设计模式可以用于实现订单状态的变化和通知。在这篇文章中，我们将介绍如何使用Golang来实现观察者设计模式，并提供一个基于订单处理系统的代码示例。
什么是观察者设计模式？
观察者设计模式是一种行为型设计模式，它允许对象之间的松耦合通信。在这种模式中，一个对象（称为主题Subject）维护一组依赖于它的对象（称为观察者Observer）的列表，并在状态改变时自动通知它们。观察者模式可以用于实现事件驱动的系统，其中对象之间的交互是通过事件的发布和订阅来完成的。
应用场景：订单处理系统
在订单处理系统中，订单的状态可能会发生变化，例如创建、支付、发货、取消等。当订单状态发生变化时，我们希望通知相关的观察者进行相应的处理，例如更新库存、发送通知等。
实现观察者设计模式
在Golang中，可以使用channel和goroutine来实现观察者设计模式。
首先，我们定义一个订单结构体，包含订单的基本信息和状态：
type Order struct {ID stringStatus string}
然后，我们定义一个观察者接口，包含一个Update方法，用于处理订单状态变化的通知：type Observer interface {Update(order *Order, wg *sync.WaitGroup)}
接下来，我们定义一个主题结构体，使用channel和goroutine来通知观察者：
type Subject struct {observers []Observer}func (s *Subject) Register(observer Observer) {s.observers = append(s.observers, observer)}func (s *Subject) Notify(order *Order) {wg := sync.WaitGroup{}wg.Add(len(s.observers))errCh := make(chan error, len(s.observers))for _, observer := range s.observers {go func(obs Observer) {defer wg.Done()err := obs.Update(order, &wg)if err != nil {errCh <- err}}(observer)}wg.Wait()close(errCh)// 处理异常for err := range errCh {fmt.Println("Error occurred:", err)}}
我们首先创建了一个errCh（类型为chan error）来接收观察者处理过程中可能发生的异常。然后，在每个观察者的goroutine中，我们通过闭包的方式传递observer并在处理完成后检查是否有异常发生。如果有异常，我们将其发送到errCh中。
在Notify方法的最后，我们关闭了errCh通道，并通过range循环来处理所有的异常。
接下来，我们实现两个观察者：库存观察者和通知观察者。
库存观察者用于更新库存状态：
type InventoryObserver struct{}func (io *InventoryObserver) Update(order *Order, wg *sync.WaitGroup) {defer wg.Done()// 更新库存状态fmt.Printf("Inventory Observer: Order %s status changed to %s\n", order.ID, order.Status)}
通知观察者用于发送通知：
type NotificationObserver struct{}func (no *NotificationObserver) Update(order *Order, wg *sync.WaitGroup) {defer wg.Done()// 发送通知fmt.Printf("Notification Observer: Order %s status changed to %s\n", order.ID, order.Status)}
最后，我们在主函数中使用观察者模式来处理订单状态变化的通知：
func main() {order := &Order{ID: "123",Status: "Created",}subject := &Subject{}subject.Register(&InventoryObserver{})subject.Register(&NotificationObserver{})// 模拟订单状态变化order.Status = "Paid"subject.Notify(order)order.Status = "Shipped"subject.Notify(order)}
我们创建了一个订单对象和一个主题对象，并注册了库存观察者。然后，我们模拟订单状态的变化，通过调用Notify方法并发地通知观察者进行处理。
通过使用channel和goroutine，我们可以实现观察者模式的并发处理，提高系统的性能和响应能力。
使用观察者设计模式的一些优点
松耦合：观察者模式可以将观察者和主题（或被观察者）对象解耦。观察者只需要关注主题的状态变化，而不需要了解具体的实现细节。这样可以使得系统更加灵活和可扩展。
可重用性：通过将观察者和主题对象分离，可以使得它们可以在不同的上下文中重复使用。例如，可以在不同的业务场景中使用相同的观察者来处理不同的主题对象。
易于扩展：当需要添加新的观察者或主题时，观察者模式可以很方便地进行扩展。只需要实现新的观察者或主题对象，并注册到主题对象中即可。
事件驱动：观察者模式适用于事件驱动的系统。当主题对象的状态发生变化时，可以通过触发事件来通知所有的观察者进行相应的处理。
如果不使用观察者设计模式
订单业务可能会以一种更加紧耦合的方式实现。以下是一个示例代码，展示了在没有使用观察者模式的情况下，如何处理订单状态变化的问题：
type Order struct {ID stringStatus string}type OrderProcessor struct {inventoryObserver *InventoryObservernotificationObserver *NotificationObserver}func NewOrderProcessor() *OrderProcessor {return &OrderProcessor{inventoryObserver: &InventoryObserver{},notificationObserver: &NotificationObserver{},}}func (op *OrderProcessor) Process(order *Order) {// 更新库存op.inventoryObserver.Update(order)// 发送通知op.notificationObserver.Update(order)}func main() {order := &Order{ID: "123",Status: "Created",}op := NewOrderProcessor()// 模拟订单状态变化order.Status = "Paid"op.Process(order)order.Status = "Shipped"op.Process(order)}
在这个示例中，OrderProcessor对象负责处理订单状态变化。它内部包含了InventoryObserver和NotificationObserver对象，并在Process方法中依次调用它们的Update方法来处理订单状态变化。
这种实现方式存在一些问题：
紧耦合：
OrderProcessor对象直接依赖于InventoryObserver和NotificationObserver对象。如果需要添加或删除其他观察者，需要修改OrderProcessor的代码，导致代码的可维护性和可扩展性下降。代码重复：每当有新的观察者需要处理订单状态变化时，都需要在
OrderProcessor中添加相应的代码。这样会导致代码的重复和冗余。可扩展性差：在没有使用观察者模式的情况下，很难在系统中添加新的观察者，因为每次都需要修改
OrderProcessor的代码。
好了，今天的小知识你学会了吗？
链接：https://juejin.cn/post/7320169878643359744
（版权归原作者所有，侵删）
微信扫码关注该文公众号作者