一、需求
外出游玩之前，必不可少的准备就是查看天气预报，现在很多天气预报APP的数据都是实时更新的，那么这就涉及到几个过程：首先用户得下载APP，也就是需要一个数据展示器。然后气象站的后台数据需要实时更新，并且这个更新需要让APP知悉。那么我们如何设计这样一个程序模拟气象站呢？
二、建模
通过需求可以知道，气象站后台是一个被观察者，它的数据可以被观察者观察。所以不难看出，观察者模式最基本的对象有两个：观察者（Observer）和被观察者（Observable）。接下来我们进行初步设计。
三、初步设计
根据第一章所提到的原则，我们需要面向接口编程而不是面向实现编程。但是不是在所有场合下类都要实现一个接口呢？答案是否定的。那为什么这里需要实现接口呢？观察者模式其实是一个一对多的关系（《HeadFirst设计模式》说的），一个被观察者可以被多个观察者观察。也就是说，多个观察者可能并不是同一个类的实例，所以需要用接口统一起来。回到生活中，一家报社的报纸可以被多个客户订阅，一个客户也可以订阅多家报社的报纸，所以我觉得观察者模式应该是多对多的关系，一对多只是多对多的一种特例。同理，被观察者也需要有一个统一的接口。
初步设计类图如图1所示：
被观察者代码如下所示：
/**
* Created by 程序猿 on 2018/1/8 0008.
* 气象站后台，相当于被观察者
*/
public class WeatherDataimplements Observalbe {
private Listobservers =new ArrayList<>();
Datadata =new Data(1.01111f, 1.0f, 1.0f);
/*
添加观察者
*/
@Override
public void addObserver(Observer observer) {
observers.add(observer);
}
/*
移除观察者
*/
@Override
public void removeObserver(Observer observer) {
if (observers.indexOf(observer) >=0){
observers.remove(observer);
}
}
/*
检测数据变化
*/
@Override
public void measureChange() {
data.setHum(2.0001f);
//data.setPress(3.0001f);
notifyObservers();
}
/*
通知观察者
*/
@Override
public void notifyObservers() {
for (int i=0; i< observers.size(); i++){
observers.get(i).update(data);
}
}
}
观察者代码大同小异，为了节省篇幅这里只放湿度展示器的代码：
/**
* Created by 程序猿 on 2018/1/8 0008.
* 湿度展示器，相当于观察者
*/
public class HumDisplayimplements Observer {
private Observalbeobservalbe;
/*
接收到后台传来的更新数据
*/
@Override
public void update(Data data) {
display(data);
}
/*
数据展示
*/
@Override
public void display(Data data) {
System.out.println("Hum：" + data.getHum());
}
/*
注册监听器
*/
@Override
public void register(Observalbe observalbe) {
this.observalbe = observalbe;
this.observalbe.addObserver(this);
}
/*
取消注册
*/
@Override
public void unregister() {
this.observalbe.removeObserver(this);
}
}
可以看出，上述代码有两个缺点：
1、当湿度变化时，湿度展示器应当更新数据，这个毋庸置疑，但是气压展示器也会收到一条没更新的数据，展示在布告板中。只能说这里的被观察者设计得不太合理，应该针对不同的数据进行拆分，也就是说将WeatherData拆分成HumData和PressData两个被观察者，然后观察者根据自己所需的数据分别进行监听。
2、监听者只能被动地接收数据，而不是主动获取，这种设计并不灵活，因此Java API提供了两种获取方式，接下来我们做进一步改进。
四、改进方案
先简述一下改进思路：主动和被动都牵涉到观察者的update()方法，因为这个方法是数据交接的入口，主动是从Observalbe获取数据，被动是Observable将Data推过去。我们的改进策略是直接继承Java原生API的Observalbe抽象类和实现Java原生API的Observer接口。为什么Observalbe是抽象类而不是接口？原因很简单，因为它已经将被观察者的共同行为实现了，比如监听变化、添加/删除观察者，从而简化程序员对被观察者代码的编写。具体可参考Java的源码，这里不做过多描述。改良后的代码如下所示：
WeatherData：
/**
* Created by 程序猿 on 2018/1/8 0008.
* 气象站后台，相当于被观察者
*/
public class WeatherData extends Observable {
private Datadata =new Data(1.01111f, 1.0f, 1.0f);
/*
改变数据
*/
public void changeData(){
data.setPress(2.0001f);
data.setHum(3.0001f);
setChanged();
notifyObservers(data);
}
public DatagetData() {
return data;
}
}
HumDisplay：
/**
* Created by 程序猿 on 2018/1/8 0008.
* 湿度展示器，相当于观察者
*/
public class HumDisplayimplements Observer {
@Override
public void update(Observable o, Object arg) {
WeatherData data = (WeatherData) o;
System.out.println("Hum：" + data.getData().getHum());
}
}
上述代码简单了很多，但与改良之前仍有一些不同，这里的注册操作交给了Observable抽象类，为的是代码重用，而不是每次都要在Observer的实现类中实现。当然也可以将Observer设计成抽象类，但是Java是一门单继承语言，一旦继承了Observer就不能继承其他类了，这里要在继承和实现中做一个取舍，孰好孰坏在不同的场合中答案不一样。
五、观察者模式
《HeadFirst设计模式》中是这样定义观察者模式的：观察者模式定义了对象之间的一对多关系，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
Java中的GUI大量地使用了观察者模式。当点击事件发生时，会触发相应的业务逻辑，点击事件就是被监听者，触发的业务逻辑则被定义在监听者中。
监听器模式有什么作用？其实就是为了建立两个对象之间的联系，当一个对象发生变化时，另一个对象会接收通知。
六、结合设计原则分析
1、变化部分和固定部分分离：被观察者的状态、观察者的数量种类会改变，将观察者与被观察者分离，可以在不改变被观察者的情况下，改变观察者。
2、针对接口编程而不针对实现编程：观察者利用被观察者的接口向被观察者注册，被观察者利用观察者的接口通知观察者。
3、多用组合，少用继承：通过集合将多个观察者组合进被观察者之中，在运行时可以动态改变观察者。