《HeadFirst设计模式》第二章观察者模式-读书笔记

By | 2019年9月27日

《HeadFirst设计模式》第二章观察者模式-读书笔记

1. 背景

这次的引子是关于气象站的应用,案例中要建立一个应用,有三种天气预报的展现形式,使用一个WeatherObject对象获得最新测量到的天气数据,然后对三个布告板进行实时更新。并且以后可能会新加入其他的布告板,需要系统有很高的扩展性。WeatherData对象知道如何跟物理气象站联系,以取得更新的数据。WeatherData对象会随即更新三个布告板的显示:目前状况(温度、湿度、气压)、气象统计和天气预报。

这是WeatherData类

2. 需求分析

2.1 WeatherData类具有getter方法,可以取得三个测量值:温度、湿度与气压。

2.2 当新的测量数据备妥时,measurementsChanged()方法就会被调用(我们不在乎此方法是如何被调用的,我们只在乎它被调用了)。

2.3 我们需要实现三个使用天气数据的布告板:“目前状况”布告、“气象统计”布告、“天气预报”布告。一旦WeatherData有新的测量,这些布告必须马上更新。

2.4 此系统必须可扩展,让其他开发人员建立定制的布告板, 用户可以随心所欲地添加或删除任何布告板。目前初始的布告板有三类:“目前状况”布告、“气象统计”布告、“天气预报”布告。

3.开始干活

3.1 先来试一下

这是最简单的实现办法,很快就可以将数据完成更新,但是如果从开发原则上考虑,这样的代码太过于粗糙,三个update方法虽然不多,但如果后期再增加布告板,update方法的调用将会一直增加,不论增加还是删除布告板都会修改程序。

这段程序就是针对具体实现编程,而不是针对接口编程,我们需要将相似的地方封装起来。

4.开始我们的观察者模式

4.1 认识观察者模式

我们看看报纸和杂志的订阅是怎么回事:

  1. 报社的业务就是出版报纸。

  2. 向某家报社订阅报纸,只要他们有新报纸出版,就会给你送来。

    只要你是他们的订户,你就会一直收到新报纸。

  3. 当你不想再看报纸的时候,取消订阅,他们就不会再送新报纸来。

  4. 只要报社还在运营,就会一直有人(或单位)向他们订阅报纸或取消订阅报纸。

定义观察者模式

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

观察者模式定义了一系列对象之间的一对多关系。

当一个对象改变状态,其他依赖者都会收到通知。

4.2 松耦合的威力

当两个对象之间松耦合,它们依然可以交互,但是不太清楚彼此的细节。
观察者模式提供了一种对象设计,让主题和观察者之间松耦合。

关于观察者的一切,主题只知道观察者实现了某个接口(也就是Observer接口)。主题不需要知道观察者的具体类是谁、做了些什么或其他任何细节。
任 何 时 候 我 们 都 可 以 增 加 新 的 观 察 者 。 因 为 主 题 唯 一 依 赖 的 东 西 是 一 个 实 现Observer接口的对象列表,所以我们可以随时增加观察者。事实上,在运行时我们可以用新的观察者取代现有的观察者,主题不会受到任何影响。同样的,也可以在任何时候删除某些观察者。

改变主题或观察者其中一方,并不会影响另一方。因为两者是松耦合的,所以只要他们之间的接口仍被遵守,我们就可以自由地改变他们。

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

5.重新开始开发

5.1 设计气象站

5.2 实现气象站

依照前面的类图,开始编写气象站的代码

运行WeatherStation可以得到结果,由此整个代码编写完成。

发表评论

电子邮件地址不会被公开。 必填项已用*标注