Go设计模式(18)-观察者模式

终于写完了创建型和结构型设计模式（共12个），现在开始写行为型设计模式（共11个）。观察者模式的应用场景非常广泛，小到代码层面的解耦，大到架构层面的系统解耦，再或者一些产品的设计思路，都有这种模式的影子。

UML类图位置：https://www.processon.com/view/link/60d29bf3e401fd49502afd25

本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/design/18observer.go

1.定义

1.1观察者模式

观察者模式：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。

UML：

1.2分析

观察者模式算是比较通用的设计模式了，思路也比较清晰。Subject里有Observer集合，当Subject有更新时，通知各个Observer。Subject为了管理Observer，自身设置了增加、删除功能。

当Subject有更新，通知Observer时，有很多细节值得讨论。

第一个问题是使用同步阻塞还是异步非阻塞

同步阻塞是最经典的实现方式，主要是为了代码解耦；
异步非阻塞除了能实现代码解耦之外，还能提高代码的执行效率；

第二个问题是如何保证所有Observer都通知成功。

方案一是利用消息队列ACK的能力，Observer订阅消息队列。Subject只需要确保信息通知给消息队列即可。
方案二是Subject将失败的通知记录，方便后面进行重试。
方案三是定义好规范，例如只对网络失败这种错误进行记录，业务失败类型不管理，由业务自行保证成功。

第三个问题是不同进程/系统如何进行通知。

进程间的观察者模式解耦更加彻底，一般是基于消息队列来实现，用来实现不同进程间的被观察者和观察者之间的交互。

2.使用场景

观察者模式的使用场景还是很多的，它和享元模式一样，更多体现的是一种设计理念。

记得前些日子遇到一个场景，正好使用的是观察者模式。商家购买服务的订单，有多个状态，如交易成功、交易取消、开始履约等。业务场景只关注交易成功、交易取消和开始履约。如果不使用观察者模式，可以用if-else解决这个问题。但各个状态的处理逻辑比较复杂，而且状态有可能存在乱序的情况，导致要处理的case更多了。这时候用观察者模式就很合适，订单状态变更为Subject，具体处理逻辑为Observer，状态变更时，通知所有处理逻辑，谁合适处理便由谁处理。不但隔离性变好，扩展性也增强了。

3.代码实现

package main

import "fmt"

type PurchaseOperFunc func(status string, data string) (res bool, err error)

/**
 * @Author: Jason Pang
 * @Description: 注册的观察者
 */
var PurchaseOperFuncArr = []PurchaseOperFunc{
    
    
   create,
   isDeleted,
   apply,
}

/**
 * @Author: Jason Pang
 * @Description: 用于创建的观察者
 * @param status
 * @param data
 * @return res
 * @return err
 */
func create(status string, data string) (res bool, err error) {
    
    
   if status == "create" {
    
    
      fmt.Println("开始创建")
      return true, nil
   }
   return true, nil
}

/**
 * @Author: Jason Pang
 * @Description: 用于删除的观察者
 * @param status
 * @param data
 * @return res
 * @return err
 */
func isDeleted(status string, data string) (res bool, err error) {
    
    
   if status == "delete" {
    
    
      fmt.Println("开始删除")
      return true, nil
   }
   return true, nil
}

/**
 * @Author: Jason Pang
 * @Description: 用于履约的观察者
 * @param status
 * @param data
 * @return res
 * @return err
 */
func apply(status string, data string) (res bool, err error) {
    
    
   if status == "apply" {
    
    
      fmt.Println("开始履约")
      return true, nil
   }
   return true, nil
}

func main() {
    
    
   status := "create"
   data := "订单数据"
   //有状态更新时，通知所有观察者
   for _, oper := range PurchaseOperFuncArr {
    
    
      res, err := oper(status, data)
      if err != nil {
    
    
         fmt.Println("操作失败")
         break
      }
      if res == false {
    
    
         fmt.Println("处理失败")
         break
      }
   }
}

输出：

➜ myproject go run main.go

开始创建

这个代码是个简单版，但整体逻辑是一样的。这种写法的好处有如下几个：

如果要处理新的状态，则实现后再PurchaseOperFuncArr添加即可，改动不大
根据具体业务来说，只能有一个逻辑是真正负责执行的，所以有一个错误就报错，然后重试即可。不过具体逻辑需要做好幂等

总结

实际上，设计模式要干的事情就是解耦。创建型模式是将创建和使用代码解耦，结构型模式是将不同功能代码解耦，行为型模式是将不同的行为代码解耦，具体到观察者模式，它是将观察者和被观察者代码解耦。

最后

大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）

我的个人博客为：https://shidawuhen.github.io/

往期文章回顾：

招聘

设计模式

语言

架构

存储

网络

工具

读书笔记

思考