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

用脱口秀大会来讲「观察者模式」_第1张图片

最近正在热播的脱口秀大会,想必大家都看过了吧,那这次我来带着大家来看下大会上的观察者模式吧。

用脱口秀大会来讲「观察者模式」_第2张图片

一、脱口秀

首先是脱口秀的角色划分:

我们把脱口秀演员:当做一个被被观察者(Observable)。

4 位领笑员 + 180 位观众,当做观察者(Observer)。

用脱口秀大会来讲「观察者模式」_第3张图片

领笑员的职责:当脱口秀演员表现好时,拍灯,表示非常好笑。

观众的职责:当脱口秀演员表现好时,拿起手中的遥控器,按下按键表示非常喜欢。

这种场景就非常符合观察者模式了,简单来说就是一批观察者对要观察的对象进行观察,对观察对象进行反应。

说完上面的例子,想必大家对观察者模式已经有了初步的印象了。

那我们再来看看在程序设计的世界中,观察者模式是怎么样的。

二、观察者模式

GoF 设计模式那本书中讲到:在对象之间定义一个一对多的依赖,当一个对象状态改变的时候,所有依赖的对象都会自动收到通知,这就是观察者模式。

观察者模式有很多其他称呼,比如发布订阅,监听回调等等,其实只要场景符合上面的描述,都可以叫做观察者模式。

Java API 内置了观察者模式,非常方便使用。用法:java.util 包内包含最基本的 Observer 接口(观察者接口)和 Observable 类(被观察者父类)。另外他们之间可以用推(push)或拉(pull)的方式传送数据。

另外很重要的一点:被观察者和观察者之间的关系是一对多的。如上面的脱口秀的例子,观众是很多个,演员一次只有一个(或一个脱口秀组合)。

三、被观察者怎么工作的?

只需要这个类继承 Observable 类即可。我来带着大家看下这个 Observable 类的构成。

添加观察者

我们首先想一下,我们想要观察别人的时候,是不是就需要被添加成别人的观察者,那么就需要一个添加观察者的方法,Observale 给我们提供了一个添加成为别人的观察者的方法:addObserver。

存放观察者

当有很多想要成为观察者的时候,是不是就得有个地方专门来存这些观察者?

Observable 给我们提供了一个存放所有观察者的地方:一个 Vector 集合。

用脱口秀大会来讲「观察者模式」_第4张图片

移除观察者

当我们不想被某个人观察,是不是就移除掉就可以了。

Observable 给我们提供了一个移除观察者的方法:deleteObserver。

用脱口秀大会来讲「观察者模式」_第5张图片

被观察者如何发出通知?

当被观察对象,想告诉观察者,他的状态已经变了,是不是就要发个通知?

Observable 给我们提供了两个方法:

notifyObservers() 或 notifyObservers(Object arg)。

区别就是一个带参,一个不带参。不带参的方式常用在观察者通过 pull 的方式来获取数据。

如下图所示,通过 push 的方式通知观察者。

用脱口秀大会来讲「观察者模式」_第6张图片

那么通知的具体细节是怎么样的?

说白了,就三步:

  • 被观察对象,先判断自己状态是否有改变。

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

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

用脱口秀大会来讲「观察者模式」_第7张图片

演员的每次的梗说完后,都会调用 setChanged() 方法,和 notifyObservers(参数) 来通知观察者,然后所有观察者的 update 方法都会被触发。

来看下演员通知的代码:

用脱口秀大会来讲「观察者模式」_第8张图片

执行结果如下,王勉的表现非常精彩,领笑员拍灯了!

用脱口秀大会来讲「观察者模式」_第9张图片

好了,观察者模式还是挺有意思的。那在电商中如何应用的呢?

六、关于设计模式

上面关于观察者和被观察者的工作原理有些坑,不知道大家注意到没?

  • 观察者需要被添加到具体某个被观察者的集合中,才能观察,相当于面向细节了,违背了面向抽象的原则。

  • 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:跨机器怎么通信?

  • 还是引入消息队列。

八、电商中应用

商品库存可以作为一个被观察者,商品入库单作为观察者,当商品库存变了后,需要生成一个商品入库单,就可以用观察者模式,商品入库单和商品库存进行解耦,如果后续还要生成其他类型的入库单再加上发送一条消息给管理员,直接添加观察者就可以了。

九、后记

本篇通过脱口秀大会来讲解观察者模式,涉及到了三种角色,领笑员,观众,脱口秀演员。

然后详细讲解了观察者和被观察者的工作原理,另外探讨了这种模式有哪些设计模式相关的问题。

然后从架构设计的角度来分析了观察者模式引入的问题:同步调用,跨进程通信,跨机器通信。

最后简单讲了下电商中的应用场景,抛转引玉,希望大家留言探讨。

你可能感兴趣的:(观察者模式,学习,java,程序人生)