一、需求

        外出游玩之前，必不可少的准备就是查看天气预报，现在很多天气预报APP的数据都是实时更新的，那么这就涉及到几个过程：首先用户得下载APP，也就是需要一个数据展示器。然后气象站的后台数据需要实时更新，并且这个更新需要让APP知悉。那么我们如何设计这样一个程序模拟气象站呢？

二、建模

        通过需求可以知道，气象站后台是一个被观察者，它的数据可以被观察者观察。所以不难看出，观察者模式最基本的对象有两个：观察者（Observer）和被观察者（Observable）。接下来我们进行初步设计。

三、初步设计

        根据第一章所提到的原则，我们需要面向接口编程而不是面向实现编程。但是不是在所有场合下类都要实现一个接口呢？答案是否定的。那为什么这里需要实现接口呢？观察者模式其实是一个一对多的关系（《HeadFirst设计模式》说的），一个被观察者可以被多个观察者观察。也就是说，多个观察者可能并不是同一个类的实例，所以需要用接口统一起来。回到生活中，一家报社的报纸可以被多个客户订阅，一个客户也可以订阅多家报社的报纸，所以我觉得观察者模式应该是多对多的关系，一对多只是多对多的一种特例。同理，被观察者也需要有一个统一的接口。

初步设计类图如图1所示：

图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、多用组合，少用继承：通过集合将多个观察者组合进被观察者之中，在运行时可以动态改变观察者。