观察者模式：定义了对象之间的一对多依赖，这样依赖，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
观察者模式有两个重要主体，一个是主题，一个是观察者。观察者能订阅主题，在主题的数据改变后，主题会将数据推送给订阅的观察者，这就是观察者模式基本结构，类图如下。
现在我们以气象站和布告板为例，分析和优化观察者模式的设计思路。首先我们需要了解到在本例中，气象站相当于观察者模式中的主题，布告板相当于观察者，现在有三种布告板，分别展示目前状况、气象统计和天气预报，当气象数据（温度，湿度，气压）改变时，布告板需要根据最新气象数据进行改变，最后显示修改后的数据。
下图是初版的设计方案，主体仍然是Subject和Oberser接口，这里多加了一个display接口用于将观察者的数据输出到终端。
进一步的实现：
这样设计有一个个问题：update方法的参数列表固定了，这里的设计方案将气象站的更新模式（温度-湿度-压力）耦合到了接口上，所以后期有不同更新模式的实现类就不得不修改接口参数列表来适配。
设计方案修改后，观察者可以在实现类中按需取用主题的属性来更新自身属性，不再与具体观察者的传参列表耦合。
以上的主题观察者设计实现了推的方式进行天气数据的更新（行为主体为主题），假如某个观察者想显示最新数据，但是这时主题数据并没有改变，这时就需要观察者主动拉数据了，拉的方式让观察者主动调用update方法就能实现。
在这个事例中我们其实用到了一个设计原则-松耦合设计：
第一个实现方案接口对具体的实现类耦合了，这会造成实现后续接口时会反复更改接口参数列表，这并不是我们想要的。
对于观察者模式，低耦合还有以下好处：
- 可以在运行时修改主题的观察者列表。
- 可以独立的复用主题或观察者。其他地方需要两者之一的时候可以轻易的复用，因为二者并非紧耦合。
- 对主题或观察者的修改并不会影响到另一个。
发表回复