写点什么

用脱口秀大会来讲「观察者模式」

发布于: 刚刚
用脱口秀大会来讲「观察者模式」

这是悟空的第 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 方法。


看下源码更清晰,注释都加上了。


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 方法。


如下所示:当收到通知后,做出相应反应,比如拍灯



演员的每次的梗说完后,都会调用 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 万字分布式算法总结。欢迎关注我的公众号「悟空聊架构」,免费获取资料学习。

发布于: 刚刚阅读数: 2
用户头像

用故事、大白话讲解Java、分布式、架构设计 2018.05.06 加入

公众号:「悟空聊架构」

评论

发布
暂无评论
用脱口秀大会来讲「观察者模式」