观察者模式Observer

简介

观察者模式是对象的行为模式，又叫发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新自己。

角色

• 抽象主题(Subject)：抽象主题角色把所有对观察者对象的引用保存在一个聚集（比如ArrayList对象）里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象，抽象主题角色又叫做抽象被观察者(Observable)角色。
• 具体主题(ConcreteSubject)：将有关状态存入具体观察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者(Concrete Observable)角色。
• 抽象观察者(Observer)：为所有的具体观察者定义一个接口，在得到主题的通知时更新自己，这个接口叫做更新接口。
• 具体观察者(ConcreteObserver)：存储与主题的状态自恰的状态。具体观察者角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态 像协调。如果需要，具体观察者角色可以保持一个指向具体主题对象的引用。

分类

在观察者模式中，又分为推模型和拉模型两种方式。

• 推模型:主题对象向观察者推送主题的详细信息，不管观察者是否需要，推送的信息通常是主题对象的全部或部分数据。
• 拉模型:主题对象在通知观察者的时候，只传递少量信息。如果观察者需要更具体的信息，由观察者主动到主题对象中获取，相当于是观察者从主题对象中拉数据。一般这种模型的实现中，会把主题对象自身通过更新方法传递给观察者，这样在观察者需要获取数据的时候，就可以通过这个引用来获取了。

不同

• 推模型是假定主题对象知道观察者需要的数据；而拉模型是主题对象不知道观察者具体需要什么数据，没有办法的情况下，干脆把自身传递给观察者，让观察者自己去按需要取值。
• 推模型可能会使得观察者对象难以复用，因为观察者的更新方法是按需要定义的参数，可能无法兼顾没有考虑到的使用情况。这就意味着出现新情况的时候，就可能提供新的更新方法，或者是干脆重新实现观察者；而拉模型就不会造成这样的情况，因为拉模型下，更新方法的参数是主题对象本身，这基本上是主题对象能传递的最大数据集合了，基本上可以适应各种情况的需要。

简例

抽象主题

import java.util.ArrayList;
import java.util.List;

//抽象主题
public abstract class Subject {
    List<Observer> list = new ArrayList<Observer>();

    public void add(Observer obj) {
        System.out.println("气象台(主题)添加一个听众(观察者)");
        list.add(obj);
    }

    public void remove(Observer obj) {
        System.out.println("气象台(主题)移除一个听众(观察者)");
        list.remove(obj);
    }

    //推模式
    public void notifyObserverTui(String state) {
        for (Observer observer : list) {
            observer.updateTui(state);
        }
    }

    //拉模式
    public void notifyObserverLa() {
        for (Observer observer : list) {
            observer.updateLa(this);
        }
    }
}

具体主题

//具体主题
public class ConcreteSubject extends Subject {
    private String state;

    public String getState() {
        return state;
    }

    public void setState(String state) {
        this.state = state;
    }

    public void changeTui(String newState) {
        state = newState;//自身状态
        System.out.println("气象台(主题)发布警报：" + state);
        super.notifyObserverTui(state);
    }

    public void changeLa(String newState) {
        state = newState;////自身状态
        System.out.println("气象台(主题)发布警报：" + state);
        super.notifyObserverLa();
    }
}

抽象观察

//抽象观察者
public interface Observer {
    public void updateTui(String state);

    public void updateLa(Subject obj);
}

具体观察

//具体观察者
public class ConcreteObserver implements Observer {
    private String observerState;

    public void updateTui(String state) {
        observerState = state;
        System.out.println("通知听众(观察者):" + observerState);
    }

    public void updateLa(Subject obj) {
        observerState = ((ConcreteSubject) obj).getState();
        System.out.println("通知听众(观察者):" + observerState);
    }
}

测试

public class Main {
    public static void main(String[] args) {
        ConcreteSubject cs = new ConcreteSubject();
        Observer co = new ConcreteObserver();
        cs.add(co);
        cs.changeTui("台风来了");
        cs.changeLa("暴雨也来了");
    }
}

结果

气象台(主题)添加一个听众(观察者)
气象台(主题)发布警报：台风来了
通知听众(观察者):台风来了
气象台(主题)发布警报：暴雨也来了
通知听众(观察者):暴雨也来了

JDK运用

在Java中通过Observable类和Observer接口实现了观察者模式。一个Observer对象监视着一个Observable对象的变化，当Observable对象发生变化时，Observer得到通知，就可以进行相应的工作。
如果画面A是显示数据库里面的数据，而画面B修改了数据库里面的数据，那么这时候画面A就要重新Load,这时候就可以用到观察者模式。

observable类

package liang;

import java.util.Observable;

public class SubjectObj extends Observable {

    private String state = "";

    public String getState() {
        return state;
    }

    public void setState(String state) {
        this.state = state;
    }

    public void add(ObserverObj obj) {
        addObserver(obj);//让观察者达到观察被观察者的目的
    }

    public void change(String newState) {
        if (!this.state.equals(newState)) {
            this.state = newState;
            setChanged();//用来设置一个内部标志位注明数据发生了变化
            notifyObservers();//通知所有的Observer数据发生了变化，这时所有的Observer会自动调用复写好的update
            //注意：只有在setChange()被调用后，notifyObservers()才会去调用update()，否则什么都不干
        }
    }
}

observer接口

public class ObserverObj implements Observer {

    public void update(Observable o, Object arg) {
        System.out.println("状态改变:" + ((SubjectObj) o).getState());
    }
}

测试

public class Main {
    public static void main(String[] args) {
        SubjectObj subject = new SubjectObj();
        ObserverObj observer = new ObserverObj();
        subject.addObserver(observer);
        subject.change("1");
        subject.change("1");//第二次change(1)时由于没有setChange，所以update没被调用
        subject.change("3");
        subject.change("4");
    }
}

结果

状态改变:1
状态改变:3
状态改变:4

注意：在Observer对象销毁前一定要用deleteObserver将其从列表中删除，也就是在onDestroy()方法中调用deleteObserver()方法。
不然因为还存在对象引用的关系，Observer对象不会被垃圾收集，造成内存泄漏，并且已死的Observer仍会被通知到，有可能造成意料外的错误，而且随着列表越来越大，notifyObservers操作也会越来越慢。

优点

• 支持松耦合和减少依赖性:客户端不再依赖于观察器，因为通过使用主体和 Observer 接口对客户端进行了隔离。 许多框架具有此优点，在这些框架中的应用程序组件可以注册为当（低级）框架事件发 生时得到通知。结果，框架将调用应用程序组件，但不会依赖于它。
• 提高了应用程序的可维护性和重用性:面向对象设计的一个原则是：系统中的每个类将重点放在某一个功能上，而不是其他方面。一个对象只做一件事情，并且将他做好。观察者模式在模块之间划定了清晰的界限，提高了应用程序的可维护性和重用性。
• 观察器数目可变:观察器可以在运行时附加和分离，因为主体对于观察器数目没有任何假定。此功能在这样的情况下是很有用的：观察器数在设计时是未知的。例如，如果用户在应用程序中打开的每个窗口都需要一个观察器。

缺点

• 性能降低:在许多实现中，观察器的 update() 方法可能与主体在同一线程中执行。如果观察器列表很长，则执行 Notify() 方法可能需要很长时间。抽取对象依赖性并不意味着添加观察器对应用程序没有任何影响。
• 内存泄漏：在 Observer 中使用的回调机制（当对象注册为以后调用时）会产生一个常见的错误，从而导致内存泄漏，甚至是在托管的 C# 代码中。假定观察器超出作用范围，但忘记取消对主体的订阅，那么主体仍然保留对观察器的引用。此引用防止垃圾收集在主体对象也被破坏之前重新分配与观察器关联的内存。如果观察器的生存期比主体的生存期短得多（通常是这种情况），则会导致严重的内存泄漏。
• 隐藏的依赖项：观察器的使用将显式依赖性（通过方法调用）转变为隐式依赖性（通过观察器）。如果在整个应用程序中广泛地使用观察器，则开发人员几乎不可能通过查看源代码来了解所发生的事情。这样，就使得了解代码更改的含意非常困难。此问题随传播级别急剧增大（例如，充当 Subject 的观察器）。因此，应该仅在少数定义良好的交互（如 Model-View-Controller 模式中模型和视图之间的交互）中使用观察器。最好不要在域对象之间使用观察器。
• 测试 / 调试困难：尽管松耦合是一项重大的体系结构功能，但是它可以使开发更困难。将两个对象去耦的情况越多，在查看源代码或类的关系图时了解它们之间的依赖性就越难因此，仅当可以安全地忽略两个对象之间的关联时才应该将它们松耦合（例如，如果观察器没有副作用）。

Head First 设计模式(中文版)的示例:

码云地址:https://gitee.com/manusas/ObserverDP

我只是大自然的搬运工,从这里:

hxxp://blog.csdn.net/tianjf0514/article/details/7475164/

hxxp://www.cnblogs.com/java-my-life/archive/2012/05/16/2502279.html

hxxp://blog.csdn.net/zhshulin/article/details/38708351