观察者模式

Posted 2020-10-26 zailushang1996

一、引子

还记得警匪片上，匪徒们是怎么配合实施犯罪的吗？一个团伙在进行盗窃的时候，总    有一两个人在门口把风——如果有什么风吹草动，则会立即通知里面的同伙紧急撤退。也许放风的人并不一定认识里面的每一个同伙；而在里面也许有新来的小弟不认识这个放风的。但是这没什么，这个影响不了他们之间的通讯，因为他们之间有早已商定好的暗号。

呵呵，上面提到的放风者、偷窃者之间的关系就是观察者模式在现实中的活生生的例子。

 

二、定义与结构

 

 

 

观察者（Observer）模式又名发布-订阅（Publish/Subscribe）模式。GOF给观察者模式如下定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

 

在这里先讲一下面向对象设计的一个重要原则——单一职责原则。因此系统的每个对象应该将重点放在问题域中的离散抽象上。因此理想的情况下，一个对象只做一件事情。这样在开发中也就带来了诸多的好处：提供了重用性和维护性，也是进行重构的良好的基础。

 

 

 

因此几乎所有的设计模式都是基于这个基本的设计原则来的。观察者模式的起源我觉得应该是在GUI和业务数据的处理上，因为现在绝大多数讲解观察者模式的例子都是这一题材。但是观察者模式的应用决不仅限于此一方面。

 

 

 

下面我们就来看看观察者模式的组成部分。

 

 

 

1)        抽象目标角色（Subject）：目标角色知道它的观察者，可以有任意多个观察者观察同一个目标。并且提供注册和删除观察者对象的接口。目标角色往往由抽象类或者接口来实现。

 

2)        抽象观察者角色（Observer）：为那些在目标发生改变时需要获得通知的对象定义一个更新接口。抽象观察者角色主要由抽象类或者接口来实现。

 

3)        具体目标角色（Concrete Subject）：将有关状态存入各个Concrete Observer对象。当它的状态发生改变时, 向它的各个观察者发出通知。

 

4)        具体观察者角色（Concrete Observer）：存储有关状态，这些状态应与目标的状态保持一致。实现Observer的更新接口以使自身状态与目标的状态保持一致。在本角色内也可以维护一个指向Concrete Subject对象的引用。

 

 

 可以看得出来，在Subject这个抽象类中，提供了上面提到的功能，而且存在一个通知方法：notify。还可以看出来Subject和ConcreteSubject之间可以说是使用了模板模式（这个模式真是简单普遍到一不小心就用到了）。

 

       这样当具体目标角色的状态发生改变，按照约定则会去调用通知方法，在这个方法中则会根据目标角色中注册的观察者名单来逐个调用相应的update方法来调整观察者的状态。这样观察者模式就走完了一个流程。

 抽象目标对象

public interface Subject {
    void registerObserver(Observer o);
}

具体目标对象

public class WeatherData implements Subject {
    private ArrayList observers;
    private float temperature;
    private float humidity;
    private float pressure;

    public WeatherData() {
        observers = new ArrayList();
    }

    @Override
    public void registerObserver(Observer o) {
        observers.add(o);
    }

    public void removeObserver(Observer observer) {
        int i = observers.indexOf(observer);
        if (i > 0) {
            observers.remove(i);
        }
    }

    public void notifyObservers() {
        for (int i = 0; i < observers.size(); i++) {
            Observer observer = (Observer) observers.get(i);
            observer.update(temperature, humidity, pressure);
        }
    }

    public void measurementsChanged() {
        notifyObservers();
    }

    public void setMeasurements(float temperature, float humidity, float pressure) {
        this.temperature = temperature;
        this.humidity = humidity;
        this.pressure = pressure;
        measurementsChanged();
    }
}

抽象观察者

public interface Observer {
    void update(float temp, float humidity, float pressure);
}

具体观察者

public class CurrentConditionDisplay implements Observer, DisplayElement {

    private float temperature;
    private float humidity;
    private Subject weatherData;

    public CurrentConditionDisplay(Subject weatherData) {
        this.weatherData = weatherData;
        weatherData.registerObserver(this);

    }

    @Override
    public void display() {
        System.out.println("Current conditions:" + temperature + "," + humidity);

    }

    @Override
    public void update(float temp, float humidity, float pressure) {
        this.temperature = temp;
        this.humidity = humidity;
        display();
    }
}

测试

public class WeatherStation {
    public static void main(String[] args) {
        WeatherData weatherData = new WeatherData();
        CurrentConditionDisplay currentDisplay = new CurrentConditionDisplay(weatherData);

        weatherData.setMeasurements(80, 65, 30.4F);

        weatherData.setMeasurements(79, 79, 79);
    }
}

输出

Current conditions:80.0,65.0
Current conditions:79.0,79.0

 

四、使用情况

 

GOF给出了以下使用观察者模式的情况：

1)        当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。

2)        当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。

3)        当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。

其实观察者模式同前面讲过的桥梁、策略有着共同的使用环境：将变化独立封装起来，以达到最大的重用和解耦。观察者与后两者不同的地方在于，观察者模式中的目标和观察者的变化不是独立的，而是有着某些联系。

五、我推你拉

 

观察者模式在关于目标角色、观察者角色通信的具体实现中，有两个版本。一种情况便是目标角色在发生变化后，仅仅告诉观察者角色“我变化了”；观察者角色如果想要知道具体的变化细节，则就要自己从目标角色的接口中得到。这种模式被很形象的称为：拉模式——就是说变化的信息是观察者角色主动从目标角色中“拉”出来的。

 

还有一种方法，那就是我目标角色“服务一条龙”，通知你发生变化的同时，通过一个参数将变化的细节传递到观察者角色中去。这就是“推模式”——管你要不要，先给你啦。

 

这两种模式的使用，取决于系统设计时的需要。如果目标角色比较复杂，并且观察者角色进行更新时必须得到一些具体变化的信息，则“推模式”比较合适。如果目标角色比较简单，则“拉模式”就很合适啦。