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所示。  图22-6 Java中的观察者类图 是不是又简单了很多？那就对了！然后我们看一下我们程序的变更，先看HanFeiZi的实现类，如代码清单22-20所示。 代码清单22-20 优化后的被观察者 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 优化后的观察者 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版。