用脱口秀大会来讲「观察者模式」
这是悟空的第 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 的方式通知观察者。
那么通知的具体细节是怎么样的?
说白了,就三步:
被观察对象,先判断自己状态是否有改变。
从 vector 集合中获取所有添加的观察者。
循环遍历观察者,调用观察者的 update 方法。
看下源码更清晰,注释都加上了。
为什么要有 setChanged?
在被观察者发送通知前,被观察对象都会调用下 setChanged()
方法,标记状态已经改变了。
那为什么需要调用下这个?不调用可以吗?
当被观察对象调用 notifyObservers 方法中,会判断状态是否有改变,如果没有改变,则不会通知观察者。
这样做的好处:可以在通知观察者时有更多的弹性。如果不想持续不断地通知观察者,就可以适当地控制 setChanged 方法的调用。
其他:还可以用 clearChanged,重置 changed 状态,hasChanged 方法获取 changed 状态。
四、观察者如何工作的?
其实很简单,观察者实现了 Observer
接口就可以成为观察者。
然后观察者实现了 update 方法,就是给被观察对象来调用的。
关于推模式和拉模式的小插曲:
如果想用推模式,调用带参的 notifyObservers 方法把参数传给观察者就可以了,如果想用拉模式,就需要主动调用被观察者的 get 数据的方法,用带参的或不带参的方式通知观察者都是可以的。
五、代码实现
我们把领笑员定义为 Leader 类,观众定义成 Viewer 类,脱口秀演员定义为 Actor 类。
领笑员都在看演员表演脱口秀,需要成为演员的观察者。调用 actor.addObserver(leader) 就可以了.
观众也是类似,调用 actor.addObserver(viewer) 就好了。
根据前面讲解的原理,领笑员和观众必须继承 observer 接口,然后实现 update 方法。
如下所示:当收到通知后,做出相应反应,比如拍灯
。
演员的每次的梗说完后,都会调用 setChanged() 方法,和 notifyObservers(参数) 来通知观察者,然后所有观察者的 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:跨机器怎么通信?
还是引入消息队列。
八、电商中应用
商品库存可以作为一个被观察者,商品入库单作为观察者,当商品库存变了后,需要生成一个商品入库单,就可以用观察者模式,商品入库单和商品库存进行解耦,如果后续还要生成其他类型的入库单再加上发送一条消息给管理员,直接添加观察者就可以了。
九、后记
本篇通过脱口秀大会来讲解观察者模式,涉及到了三种角色,领笑员,观众,脱口秀演员。
然后详细讲解了观察者和被观察者的工作原理,另外探讨了这种模式有哪些设计模式相关的问题。
然后从架构设计的角度来分析了观察者模式引入的问题:同步调用,跨进程通信,跨机器通信。
最后简单讲了下电商中的应用场景,抛转引玉,希望大家留言探讨。
源码下载,在公众号回复:观察者。
欢迎关注我的公众号:「悟空聊架构
」
作者简介:8 年互联网职场老兵|全栈工程师|90 后超级奶爸|开源践行者|公众号万粉原创号主。蓝桥签约作者,著有《JVM 性能调优实战》专栏,手写了一套 7 万字 SpringCloud 实战总结和 3 万字分布式算法总结。欢迎关注我的公众号「悟空聊架构」,免费获取资料学习。
版权声明: 本文为 InfoQ 作者【悟空聊架构】的原创文章。
原文链接:【http://xie.infoq.cn/article/e6f8f36de0b4a57d8562d921f】。未经作者许可,禁止转载。
评论