1700469677
public class LiSi implements Observer{
1700469678
1700469679
//首先李斯是个观察者，一旦韩非子有活动，他就知道，他就要向老板汇报
1700469680
1700469681
public void update（Observable observable,Object obj）{
1700469682
1700469683
System.out.println（“李斯：观察到李斯活动，开始向老板汇报了……”）；
1700469684
1700469685
this.reportToQiShiHuang（obj.toString（））；
1700469686
1700469687
System.out.println（“李斯：汇报完毕……\n”）；
1700469688
1700469689
}
1700469690
1700469691
//汇报给秦始皇
1700469692
1700469693
private void reportToQiShiHuang（String reportContext）{
1700469694
1700469695
System.out.println（“李斯：报告，秦老板！韩非子有活动了–＞”+reportContext）；
1700469696
1700469697
}
1700469698
1700469699
}
1700469700
1700469701
只改变了粗体部分，应java.util.Observer接口要求update传递过来两个变量，Observable这个变量我们没用到（接口中定义必须实现的），就不处理了。其他两个观察者实现类也是相同的改动，不再赘述。
1700469702
1700469703
场景类没有改动，运行结果也完全相同，大家看看我们使用了Java提供的观察者模式后是不是简单了很多，所以在Java的世界里横行时，多看看API，有帮助很大，很多东西Java已经帮你设计了一个良好的框架了。
1700469704
1700469705
1700469706
1700469707
1700469708
设计模式之禅 22.4.2 项目中真实的观察者模式
1700469709
1700469710
为什么要说“真实”呢？因为我们刚刚讲的那些是太标准的模式了，在系统设计中会对观察者模式进行改造或改装，主要在以下3个方面。
1700469711
1700469712
❑观察者和被观察者之间的消息沟通
1700469713
1700469714
被观察者状态改变会触发观察者的一个行为，同时会传递一个消息给观察者，这是正确的，在实际中一般的做法是：观察者中的update方法接受两个参数，一个是被观察者，一个是DTO（Data Transfer Object，据传输对象），DTO一般是一个纯洁的JavaBean，由被观察者生成，由观察者消费。
1700469715
1700469716
当然，如果考虑到远程传输，一般消息是以XML格式传递。
1700469717
1700469718
❑观察者响应方式
1700469719
1700469720
我们这样来想一个问题，观察者是一个比较复杂的逻辑，它要接受被观察者传递过来的信息，同时还要对他们进行逻辑处理，在一个观察者多个被观察者的情况下，性能就需要提到日程上来考虑了，为什么呢？如果观察者来不及响应，被观察者的执行时间是不是也会被拉长？那现在的问题就是：观察者如何快速响应？有两个办法：一是采用多线程技术，甭管是被观察者启动线程还是观察者启动线程，都可以明显地提高系统性能，这也就是大家通常所说的异步架构；二是缓存技术，甭管你谁来，我已经准备了足够的资源给你了，我保证快速响应，这当然也是一种比较好方案，代价就是开发难度很大，而且压力测试要做的足够充分，这种方案也就是大家说的同步架构。
1700469721
1700469722
❑被观察者尽量自己做主
1700469723
1700469724
这是什么意思呢？被观察者的状态改变是否一定要通知观察者呢？不一定吧，在设计的时候要灵活考虑，否则会加重观察者的处理逻辑，一般是这样做的，对被观察者的业务逻辑doSomething方法实现重载，如增加一个doSomething（boolean isNotifyObs）方法，决定是否通知观察者，而不是在消息到达观察者时才判断是否要消费。
1700469725
1700469726
[
上一页 ]
[ :1.700469677e+09 ]
[
下一页 ]