用脱口秀大会来讲「观察者模式」
最近正在热播的脱口秀大会，想必大家都看过了吧，那这次我来带着大家来看下大会上的观察者模式吧。
一、脱口秀
首先是脱口秀的角色划分：
我们把脱口秀演员：当做一个被被观察者（Observable）。
4 位领笑员 + 180 位观众，当做观察者（Observer）。
观众的职责：当脱口秀演员表现好时，拿起手中的遥控器，按下按键表示非常喜欢。
这种场景就非常符合观察者模式了，简单来说就是一批观察者对要观察的对象进行观察，对观察对象进行反应。
说完上面的例子，想必大家对观察者模式已经有了初步的印象了。
那我们再来看看在程序设计的世界中，观察者模式是怎么样的。
二、观察者模式
GoF 设计模式那本书中讲到：在对象之间定义一个一对多的依赖，当一个对象状态改变的时候，所有依赖的对象都会自动收到通知，这就是观察者模式。
观察者模式有很多其他称呼，比如发布订阅，监听回调等等，其实只要场景符合上面的描述，都可以叫做观察者模式。
Java API 内置了观察者模式，非常方便使用。用法：java.util 包内包含最基本的 Observer 接口（观察者接口）和 Observable 类（被观察者父类）。另外他们之间可以用推（push）或拉（pull）的方式传送数据。
另外很重要的一点：被观察者和观察者之间的关系是一对多的。如上面的脱口秀的例子，观众是很多个，演员一次只有一个（或一个脱口秀组合）。
三、被观察者怎么工作的？
只需要这个类继承 Observable 类即可。我来带着大家看下这个 Observable 类的构成。
添加观察者
我们首先想一下，我们想要观察别人的时候，是不是就需要被添加成别人的观察者，那么就需要一个添加观察者的方法，Observale 给我们提供了一个添加成为别人的观察者的方法：addObserver。
存放观察者
当有很多想要成为观察者的时候，是不是就得有个地方专门来存这些观察者？
Observable 给我们提供了一个存放所有观察者的地方：一个 Vector 集合。
移除观察者
当我们不想被某个人观察，是不是就移除掉就可以了。
Observable 给我们提供了一个移除观察者的方法：deleteObserver。
被观察者如何发出通知？
当被观察对象，想告诉观察者，他的状态已经变了，是不是就要发个通知？
Observable 给我们提供了两个方法：
notifyObservers() 或 notifyObservers(Object arg)。
区别就是一个带参，一个不带参。不带参的方式常用在观察者通过 pull 的方式来获取数据。
如下图所示，通过 push 的方式通知观察者。
说白了，就三步：
- 被观察对象，先判断自己状态是否有改变。
- 从 vector 集合中获取所有添加的观察者。
- 循环遍历观察者，调用观察者的 update 方法。
看下源码更清晰，注释都加上了。
public void notifyObservers(Object var1) {
Object[] var2;
synchronized(this) {
//当调用 setChange() 方法后，this.changed = true
if (!this.changed) {
return;
}
// 获取所有观察者
var2 = this.obs.toArray();
// 重置 change 状态
this.clearChanged();
}
// 循环遍历通知观察者
for(int var3 = var2.length - 1; var3 >= 0; --var3) {
((Observer)var2[var3]).update(this, var1);
}
}为什么要有 setChanged？
在被观察者发送通知前，被观察对象都会调用下 setChanged() 方法，标记状态已经改变了。
protected synchronized void clearChanged() {
this.changed = false;
}那为什么需要调用下这个？不调用可以吗？
当被观察对象调用 notifyObservers 方法中，会判断状态是否有改变，如果没有改变，则不会通知观察者。
这样做的好处：可以在通知观察者时有更多的弹性。如果不想持续不断地通知观察者，就可以适当地控制 setChanged 方法的调用。
其他：还可以用 clearChanged，重置 changed 状态，hasChanged 方法获取 changed 状态。
四、观察者如何工作的？
其实很简单，观察者实现了 Observer 接口就可以成为观察者。
public interface Observer {
void update(Observable var1, Object var2);
}然后观察者实现了 update 方法，就是给被观察对象来调用的。
关于推模式和拉模式的小插曲：
如果想用推模式，调用带参的 notifyObservers 方法把参数传给观察者就可以了，如果想用拉模式，就需要主动调用被观察者的 get 数据的方法，用带参的或不带参的方式通知观察者都是可以的。
五、代码实现
我们把领笑员定义为 Leader 类，观众定义成 Viewer 类，脱口秀演员定义为 Actor 类。
领笑员都在看演员表演脱口秀，需要成为演员的观察者。调用 actor.addObserver(leader) 就可以了.
观众也是类似，调用 actor.addObserver(viewer) 就好了。
根据前面讲解的原理，领笑员和观众必须继承 observer 接口，然后实现 update 方法。
如下所示：当收到通知后，做出相应反应，比如拍灯。
来看下演员通知的代码：
好了，观察者模式还是挺有意思的。那在电商中如何应用的呢？
六、关于设计模式
上面关于观察者和被观察者的工作原理有些坑，不知道大家注意到没？
- 观察者需要被添加到具体某个被观察者的集合中，才能观察，相当于面向细节了，违背了面向抽象的原则。
- Observable 是一个类，而不是一个接口，而且 Observable 也没有实现接口，这个就违背了面向接口编程。
- 必须有一个类来继承 Observable ，如果某个类相同时拥有 Observer 类的功能，又想拥有另外一个类的功能，那么就会陷入两难，因为 Java 不支持多重继承，限制了 Observable 的复用潜力。
- 另外 Observer API 中的 setChanged() 方法被保护起来了（被定义成 protected 方法），那么除非继承 Observable，否则无法创建 Observable 实例并组合到你自己的对象中。违反了“多用组合，少用继承”的原则。
七、架构设计的问题
问题1：上面的观察者模式都是同步阻塞的方式，被观察者需要等待观察者全部执行完后，才会执行后续代码。怎么通过异步的方式来通知观察者呢？
- 方案1：启动一个线程来调用 notifyObservers 方法。
- 方案2：Google Guava EventBus 框架的设计思想
问题2：跨进程怎么通信？
- 方案1：我们看到被观察者每次都要调用观察者的 update 方法来通知观察者，所以跨进程该怎么做？我们可以同步调用 RPC 接口来实现。
- 方案2：消息队列，可以有多个消费者和生产者，消费者订阅消息，类似观察者。但是引入了消息队列，增加了维护成本。
问题3：跨机器怎么通信？
- 还是引入消息队列。
八、电商中应用
商品库存可以作为一个被观察者，商品入库单作为观察者，当商品库存变了后，需要生成一个商品入库单，就可以用观察者模式，商品入库单和商品库存进行解耦，如果后续还要生成其他类型的入库单再加上发送一条消息给管理员，直接添加观察者就可以了。
九、后记
本篇通过脱口秀大会来讲解观察者模式，涉及到了三种角色，领笑员，观众，脱口秀演员。
然后详细讲解了观察者和被观察者的工作原理，另外探讨了这种模式有哪些设计模式相关的问题。
然后从架构设计的角度来分析了观察者模式引入的问题：同步调用，跨进程通信，跨机器通信。
最后简单讲了下电商中的应用场景，抛转引玉，希望大家留言探讨。