这是悟空的第 121 篇原创文章
大家好,我是悟空。
最近正在热播的脱口秀大会,想必大家都看过了吧,那这次我来带着大家来看下大会上的观察者模式吧。
首先是脱口秀的角色划分:
我们把脱口秀演员:当做一个被被观察者
(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 的方式通知观察者。
那么通知的具体细节是怎么样的?
说白了,就三步:
看下源码更清晰,注释都加上了。
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()
方法,标记状态已经改变了。
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 方法。
如下所示:当收到通知后,做出相应反应,比如拍灯
。
演员的每次的梗说完后,都会调用 setChanged() 方法,和 notifyObservers(参数) 来通知观察者,然后所有观察者的 update 方法都会被触发。
来看下演员通知的代码:
执行结果如下,王勉的表现非常精彩,领笑员拍灯了!
源码下载,在公众号后台回复:观察者。
👇👇👇
好了,观察者模式还是挺有意思的。那在电商中如何应用的呢?
上面关于观察者和被观察者的工作原理有些坑,不知道大家注意到没?
问题1:上面的观察者模式都是同步阻塞的方式,被观察者需要等待观察者全部执行完后,才会执行后续代码。怎么通过异步
的方式来通知观察者呢?
问题2:跨进程怎么通信?
问题3:跨机器怎么通信?
商品库存可以作为一个被观察者,商品入库单作为观察者,当商品库存变了后,需要生成一个商品入库单,就可以用观察者模式,商品入库单和商品库存进行解耦,如果后续还要生成其他类型的入库单再加上发送一条消息给管理员,直接添加观察者就可以了。
本篇通过脱口秀大会来讲解观察者模式,涉及到了三种角色,领笑员,观众,脱口秀演员。
然后详细讲解了观察者和被观察者的工作原理,另外探讨了这种模式有哪些设计模式相关的问题。
然后从架构设计的角度来分析了观察者模式引入的问题:同步调用,跨进程通信,跨机器通信。
最后简单讲了下电商中的应用场景,抛转引玉,希望大家留言探讨。
- END -