Go语言设计模式之实现观察者模式解决代码臃肿(go语言开发可视化界面)

我们先来简单学习一下用 Go 实现观察者设计模式，给怎么实现事件驱动编程、事件源这些模式做个铺垫。主要也是我也老没看设计模式了，一起再复习一下。以前看的设计模式教程都是 Java 的，这次用 Go 实现一番。

观察者模式

咱们先来看一下观察者模式的概念，我尽量加一些自己的理解，让它变成咱们都能理解的大俗话：

概念

观察者模式 (Observer Pattern)，定义对象间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知，依赖对象在收到通知后，可自行调用自身的处理程序，实现想要干的事情，比如更新自己的状态。

发布者对观察者唯一了解的是它实现了某个接口（观察者接口）。这种松散耦合的设计最大限度地减少了对象之间的相互依赖，因此使我们能够构建灵活的系统来处理主体的变化。

我的理解

上面这段话看完，相信几乎对于理解观察者模式能起到的作用微乎其微，类似于现实职场里加班对项目进度起到的作用一样，加班的时候谁还没打过几把王者荣耀，嘿。下面我用自己的理解再给你们唠一下。

观察者模式也经常被叫做发布 – 订阅（Publish/Subscribe）模式、上面说的定义对象间的一种一对多依赖关系，一 – 指的是发布变更的主体对象，多 – 指的是订阅变更通知的订阅者对象。

发布的状态变更信息会被包装到一个对象里，这个对象被称为事件，事件一般用英语过去式的语态来命名，比如用户注册时，用户模块在用户创建好后发布一个事件 UserCreated 或者 UserWasCreated 都行，这样从名字上就能看出，这是一个已经发生过的事件。

事件发布给订阅者的过程，其实就是遍历一下已经注册的事件订阅者，逐个去调用订阅者实现的观察者接口方法，比如叫 handleEvent 之类的方法，这个方法的参数一般就是当前的事件对象。

至于很多人会好奇的，事件的处理是不是异步的？主要看我们的需求是什么，一般情况下是同步的，即发布事件后，触发事件的方法会阻塞等到全部订阅者返回后再继续，当然也可以让订阅者的处理异步执行，完全看我们的需求。

大部分场景下其实是同步执行的，单体架构会在一个数据库事务里持久化因为主体状态变更，而需要更改的所有实体类。

微服务架构下常见的做法是有一个事件存储，订阅者接到事件通知后，会把事件先存到事件存储里，这两步也需要在一个事务里完成才能保证最终一致性，后面会再有其他线程把事件从事件存储里搞到消息设施里，发给其他服务，从而在微服务架构下实现各个位于不同服务的实体间的最终一致性。

所以观察者模式，从程序效率上看，大多数情况下没啥提升，更多的是达到一种程序结构上的解耦，让代码不至于那么难维护。

Go 实现观察者模式

说了这么多，我们再看下用 Go 怎么实现最简单的观察者模式：

下面看一下用 Go 怎么实现事件总线。

Go 实现事件总线

下面我们实现一个支持以下功能的事件总线

异步不阻塞支持任意参数值

这个代码不是我自己写的，出处见代码注释首行。

代码

单测

总结

今天给大家用大白话瞎唠了一下观察者模式的原理和实际怎么应用，感觉文章的精髓主要在前半部分，可能有的不你还不能理解，后面我会再通过后续文章逐一解释，其实这些都是事件驱动和事件源这些模式里的基础内容。

至于这次给出的代码，其实没啥实战意义，就是大家先了解一下。Go 里边关于事件驱动之类的内容，感觉不多，有 Spring 使用经验的可以先看看 Spring 提供的@EventListener 注解，需要订阅者异步执行可以配合 @Async 注解使用，至于我上面说的需要保证事件发布的主体和订阅者的原子性持久化的话，则是通过@Transitional 和 @TransactionalEventListener 结合使用来实现。