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

气象监测应用

现在有一个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模式：

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