Head First设计模式系列二:观察者模式

本文深入探讨了观察者模式的原理及应用,通过WeatherData对象示例,解释如何在对象间建立一对多依赖关系,实现状态改变时的自动更新。文章还对比了自定义观察者模式与Java内置观察者模式的区别,指出了内置模式的局限性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

气象监测应用

现在有一个WeatherData对象,他有以下的一些方法,现在要通过这个对象,建立三个布告板:目前状况,气象统计和天气预报

这个问题在于WeatherData对象一旦有新的测量值,就会去更新面板,此外以后还会增加新的面板(WeatherData对象应该对修改封闭,不然每次增加面板就要修改WeatherData的代码会很麻烦)。

错误示例

观察者模式

类似于报纸的订阅,有新的报纸之后,就会有人邮递给你,而不用自己去取。

观察者模式:定义了对象之间的一对多依赖,当一个对象改变状态时,它的所有依赖者都会收到通知并自动更新。

从类图中可以看出:主题接口中有注册、移除、通知观察者的行为,观察者接口中有相应的更新方法。那么主题又是怎么通知观察者,观察者又是怎么注册的呢?

具体的方法在两个实现类中:主题实现类中有一个观察者列表的实例变量,注册、移除观察者,即向这个列表中添加、移除观察者,通知观察者即使用循环调用每一个观察者的update方法,注意这里面的观察者都是接口,并不是真正的类;而观察者实现类中也有一个主题接口的实例变量,通过构造方法传入该具体主题的参数,并调用主题的注册方法,由此实现注册。

这是一种松耦合的设计,主题和观察者之间可以交互,但是并不清楚彼此的细节:主题实现类只知道观察者实现了某个接口,只会调用通知方法来通知各个观察者,但并不清楚观察者会干什么,而观察者注册到相应主题之后,只是等待通知。这样,可以很方便的添加或者删除观察者。

java内置的观察者模式

可观察者(主题)要继承java.util.Observable类,类中已经有了注册、删除、通知的方法,不再需要自己写了;观察者实现Observer接口,实现update方法,观察者中还是有一个Observable的实例变量的,在构造函数中传入,并注册到可观察者中。

可观察者发出通知:先调用setChanged方法,标记状态已经改变的事实(在notifyObservers方法中会判断这个状态,状态改变了,才会通知观察者);然后调用notifyObservers()或者notifyObservers(Object arg),后者会发出数据对象,前者只是通知有变化发生,需要观察者自己来拉取数据。

观察者接受通知:实现了update(Observable o, Object arg)就可以。

内置观察者模式的缺点

内置的通知观察者的顺序是随机的,不是固定的,在需要时序控制观察者的时候就会有问题。

Observable是一个类--java的类不能多继承;而且没有Observable接口,也就无法建立自己的实现和Observer搭配使用

Observable将setChanged方法定义成了protected权限,因此只有继承自Observable,否则无法创建Observable实例并组合到自己的对象中。

在GUI编程中各种监听器都用到了观察者模式

总结

OO原则:为交互对象之间的松耦合设计而努力

OO模式:

观察者模式:在对象之间定义一对多的依赖,这样当一个对象改变状态,依赖它的对象都会收到通知并自动更新。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值