1700469610
设计模式之禅 22.3.4 观察者模式的注意事项
1700469611
1700469612
使用观察者模式也有以下两个重点问题要解决。
1700469613
1700469614
❑广播链的问题
1700469615
1700469616
如果你做过数据库的触发器，你就应该知道有一个触发器链的问题，比如表A上写了一个触发器，内容是一个字段更新后更新表B的一条数据，而表B上也有个触发器，要更新表C，表C也有触发器……完蛋了，这个数据库基本上就毁掉了！我们的观察者模式也是一样的问题，一个观察者可以有双重身份，既是观察者，也是被观察者，这没什么问题呀，但是链一旦建立，这个逻辑就比较复杂，可维护性非常差，根据经验建议，在一个观察者模式中最多出现一个对象既是观察者也是被观察者，也就是说消息最多转发一次（传递两次），这还是比较好控制的。
1700469617
1700469618
注意 它和责任链模式的最大区别就是观察者广播链在传播的过程中消息是随时更改的，它是由相邻的两个节点协商的消息结构；而责任链模式在消息传递过程中基本上保持消息不可变，如果要改变，也只是在原有的消息上进行修正。
1700469619
1700469620
❑异步处理问题
1700469621
1700469622
这个EJB是一个非常好的例子，被观察者发生动作了，观察者要做出回应，如果观察者比较多，而且处理时间比较长怎么办？那就用异步呗，异步处理就要考虑线程安全和队列的问题，这个大家有时间看看Message Queue，就会有更深的了解。
1700469623
1700469624
1700469625
1700469626
1700469627
设计模式之禅 [:1700454022]
1700469628
设计模式之禅 22.4 观察者模式的扩展
1700469629
1700469630
22.4.1 Java世界中的观察者模式
1700469631
1700469632
细心的你可能已经发现，HanFeiZi这个实现类中应该抽象出一个父类，父类完全作为被观察者的职责，每一个被观察者只实现自己的逻辑方法就可以了，如此则非常符合单一职责原则。是的，是的，确实是应该这样。幸运的是，Java从一开始诞生就提供了一个可扩展的父类，即java.util.Observable，这个类就是为那些“暴露狂”准备的，他们老是喜欢把自己的状态变更让别人去欣赏，去触发，这正符合了我们现在的要求，要把韩非子的所有活动都暴露出去，并且想暴露给谁就给暴露给谁。我们打开Java的帮助文件看看，查找一下Observable是不是已经有这个类了？JDK中提供了：java.util.Observable实现类和java.util.Observer接口，也就是说我们上面写的那个例子中的Observable接口可以改换成java.util.Observale实现类了，如图22-6所示。
1700469633
1700469634
1700469635
1700469636
1700469637
图22-6 Java中的观察者类图
1700469638
1700469639
是不是又简单了很多？那就对了！然后我们看一下我们程序的变更，先看HanFeiZi的实现类，如代码清单22-20所示。
1700469640
1700469641
代码清单22-20 优化后的被观察者
1700469642
1700469643
public class HanFeiZi extends Observable,IHanFeiZi{
1700469644
1700469645
//韩非子要吃饭了
1700469646
1700469647
public void haveBreakfast（）{
1700469648
1700469649
System.out.println（“韩非子：开始吃饭了……”）；
1700469650
1700469651
//通知所有的观察者
1700469652
1700469653
super.setChanged（）；
1700469654
1700469655
super.notifyObservers（“韩非子在吃饭”）；
1700469656
1700469657
}
1700469658
1700469659
//韩非子开始娱乐了