设计模式笔记18——观察者模式（observer）

天气预报项目需求,具体要求如下：

1) 气象站可以将每天测量到的温度，湿度，气压等等以公告的形式发布出去(比如发布到自己的网站或第三方)。

2) 需要设计开放型API，便于其他第三方也能接入气象站获取数据。

3) 提供温度、气压和湿度的接口

4) 测量数据更新时，要能实时的通知给第三方

 

天气预报设计方案1-普通方案

WeatherData类

通过对气象站项目的分析，我们可以初步设计出一个WeatherData类

说明:

1) 通过getXxx方法，可以让第三方接入，并得到相关信息.

2) 当数据有更新时，气象站通过调用dataChange() 去更新数据，当第三方再次获取时，就能得到最新数据，当然也可以推送。

 

 

这种方案存在如下问题

1) 其他第三方接入气象站获取数据的问题

2) 无法在运行时动态的添加第三方 (新浪网站)

3) 违反ocp原则=>观察者模式

 

//在WeatherData中，当增加一个第三方，都需要创建一个对应的第三方的公告板对象，并加入到dataChange, 不利于维护，也不是动态加入

public void dataChange() {

currentConditions.update(getTemperature(), getPressure(), getHumidity());

}

 

观察者模式原理

观察者模式类似订牛奶业务

1) 奶站/气象局：Subject

2) 用户/第三方网站：Observer

Subject：登记注册、移除和通知

1) registerObserver 注册

2) removeObserver 移除

3) notifyObservers() 通知所有的注册的用户，根据不同需求，可以是更新数据，让用户来取，也可能是实施推送，看具体需求定

 

Observer：接收输入

观察者模式：对象之间多对一依赖的一种设计方案，被依赖的对象为Subject，依赖的对象为Observer，Subject通知Observer变化,比如这里的奶站是Subject，是1的一方。用户时Observer，是多的一方。

 

 

思路分析图解(类图)

观察者模式的好处

1) 观察者模式设计后，会以集合的方式来管理用户(Observer)，包括注册，移除和通知。

2) 这样，我们增加观察者(这里可以理解成一个新的公告板)，就不需要去修改核心类WeatherData不会修改代码，遵守了ocp原则。

 

核心代码：

public class WeatherData implements Subject {
    public void registerObserver(Observer o) {
        // TODO Auto-generated method stub
        observers.add(o);
    }

    public void removeObserver(Observer o) {
        // TODO Auto-generated method stub
        if(observers.contains(o)) {
            observers.remove(o);
        }
    }

    @Override
    public void notifyObservers() {
        // TODO Auto-generated method stub
        for(int i = 0; i < observers.size(); i++) {
            observers.get(i).update(this.temperatrue, this.pressure, this.humidity);
        }
    }
....