22.4 观察者模式的扩展

22.4 观察者模式的扩展

22.4.1 Java世界中的观察者模式

细心的你可能已经发现,HanFeiZi这个实现类中应该抽象出一个父类,父类完全作为被观察者的职责,每一个被观察者只实现自己的逻辑方法就可以了,如此则非常符合单一职责原则。是的,确实是应该这样。幸运的是,Java从一开始诞生就提供了一个可扩展的父类, 即java.util.Observable,这个类就是为那些“暴露狂”准备的,他们老是喜欢把自己的状态变更让别人去欣赏,去触发,这正符合了我们现在的要求,要把韩非子的所有活动都暴露出去, 并且想暴露给谁就暴露给谁。我们打开Java的帮助文件看看,查找一下Observable是不是已经有这个类了?JDK中提供了:java.util.Observable实现类和java.util.Observer接口,也就是说我们上面写的那个例子中的Observable接口可以改换成java.util.Observale实现类了,如图22-6 所示。

image-20210929202341629

图22-6 Java中的观察者类图
是不是又简单了很多?那就对了!然后我们看一下我们程序的变更,先看HanFeiZi的实现类,如代码清单22-20所示。

代码清单22-20 优化后的被观察者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class HanFeiZi extends Observable,IHanFeiZi{
//韩非子要吃饭了
public void haveBreakfast(){
System.out.println("韩非子:开始吃饭了...");
//通知所有的观察者
super.setChanged();
super.notifyObservers("韩非子在吃饭");
}
//韩非子开始娱乐了
public void haveFun(){
System.out.println("韩非子:开始娱乐了...");
super.setChanged();
this.notifyObservers("韩非子在娱乐");
}
}

改变得不多,引入了一个java.util.Observable对象,删除了增加、删除观察者的方法,简单了很多,那我们再来看观察者的实现类,如代码清单22-21所示。

代码清单22-21 优化后的观察者

1
2
3
4
5
6
7
8
9
10
11
12
public class LiSi implements Observer{
//首先李斯是个观察者,一旦韩非子有活动,他就知道,他就要向老板汇报
public void update(Observable observable,Object obj){
System.out.println("李斯:观察到韩非子活动,开始向老板汇报了...");
this.reportToQinShiHuang(obj.toString());
System.out.println("李斯:汇报完毕...\n");
}
//汇报给秦始皇
private void reportToQinShiHuang(String reportContext){
System.out.println("李斯:报告,秦老板!韩非子有活动了--->"+reportContext);
}
}

只改变了粗体部分,应java.util.Observer接口要求update传递过来两个变量,Observable 这个变量我们没用到(接口中定义必须实现的),就不处理了。其他两个观察者实现类也是相同的改动,不再赘述。

场景类没有改动,运行结果也完全相同,大家看看我们使用了Java提供的观察者模式后是不是简单了很多,所以在Java的世界里横行时,多看看API,有帮助很大,很多东西Java已经帮你设计了一个良好的框架。

22.4.2 项目中真实的观察者模式

为什么要说“真实”呢?因为我们刚刚讲的那些是太标准的模式了,在系统设计中会对观察者模式进行改造或改装,主要在以下3个方面。

  • 观察者和被观察者之间的消息沟通

被观察者状态改变会触发观察者的一个行为,同时会传递一个消息给观察者,这是正确的,在实际中一般的做法是:观察者中的update方法接受两个参数,一个是被观察者,一个是DTO(Data Transfer Object,据传输对象),DTO一般是一个纯洁的JavaBean,由被观察者生成,由观察者消费。

当然,如果考虑到远程传输,一般消息是以XML格式传递。

  • 观察者响应方式

我们这样来想一个问题,观察者是一个比较复杂的逻辑,它要接受被观察者传递过来的信息,同时还要对他们进行逻辑处理,在一个观察者多个被观察者的情况下,性能就需要提到日程上来考虑了,为什么呢?如果观察者来不及响应,被观察者的执行时间是不是也会被拉长?那现在的问题就是:观察者如何快速响应?有两个办法:一是采用多线程技术,甭管是被观察者启动线程还是观察者启动线程,都可以明显地提高系统性能,这也就是大家通常所说的异步架构;二是缓存技术,甭管你谁来,我已经准备了足够的资源给你了,我保证快速响应,这当然也是一种比较好方案,代价就是开发难度很大,而且压力测试要做的足够充分,这种方案也就是大家说的同步架构。

  • 被观察者尽量自己做主

这是什么意思呢?被观察者的状态改变是否一定要通知观察者呢?不一定吧,在设计的时候要灵活考虑,否则会加重观察者的处理逻辑,一般是这样做的,对被观察者的业务逻辑doSomething方法实现重载,如增加一个doSomething(boolean isNotifyObs)方法,决定是否通知观察者,而不是在消息到达观察者时才判断是否要消费。

22.4.3 订阅发布模型

观察者模式也叫做发布/订阅模型(Publish/Subscribe),如果你做过EJB(Enterprise JavaBean)的开发,这个你绝对不会陌生。EJB2是个折腾死人不偿命的玩意儿,写个Bean要实现,还要继承,再加上那一堆的配置文件,小项目还凑合,你要知道用EJB开发的基本上都不是小项目,到最后是每个项目成员都在骂EJB这个忽悠人的东西;但是EJB3是个非常优秀的框架,还是算比较轻量级,写个Bean只要加个Annotaion就成了,配置文件减少了,而且也引入了依赖注入的概念,虽然只是EJB2的翻版,但是毕竟还是前进了一步。在EJB中有3 个类型的Bean: Session Bean、Entity Bean和MessageDriven Bean,我们这里来说一下MessageDriven Bean(一般简称为MDB),消息驱动Bean,消息的发布者(Provider)发布一个消息,也就是一个消息驱动Bean,通过EJB容器(一般是Message Queue消息队列)通知订阅者做出回应,从原理上看很简单,就是观察者模式的升级版,或者说是观察则模式的BOSS版。