观察者（Observer）模式

一、概念
  在阎宏博士的《JAVA与模式》一书中开头是这样描述观察者（Observer）模式的：

  观察者模式是对象的行为模式，又叫发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。

  观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新自己。

二、结构
     一个软件系统里面包含了各种对象，就像一片欣欣向荣的森林充满了各种生物一样。在一片森林中，各种生物彼此依赖和约束，形成一个个生物链。一种生物的状态变化会造成其他一些生物的相应行动，每一个生物都处与其他生物的互动之中。

     同样，一个软件系统常常要求在某一个对象的状态发生变化的时候，某些其他的对象做出相应的改变。做到这一点的设计方案有很多，但是为了使系统能够易于复用，应该选择低耦合度的设计方案。减少对象之间的耦合有利于系统的复用，但是同时设计师需要使这些低耦合度的对象之间能够维持行动的协调一致，保证高度的协作。观察者模式是满足这一要求的各种设计方案中最重要的一种。

     下面以一个简单的示意性实现为例，讨论观察者模式的结构。

三、所涉及的角色
  抽象主题(Subject)角色：抽象主题角色把所有对观察者对象的引用保存在一个聚集（比如ArrayList对象）里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象，抽象主题角色又叫做抽象被观察者(Observable)角色。

 具体主题(ConcreteSubject)角色：将有关状态存入具体观察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者(Concrete Observable)角色。

 抽象观察者(Observer)角色：为所有的具体观察者定义一个接口，在得到主题的通知时更新自己，这个接口叫做更新接口。

 具体观察者(ConcreteObserver)角色：存储与主题的状态自恰的状态。具体观察者角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。如果需要，具体观察者角色可以保持一个指向具体主题对象的引用。

四、推模式源代码
抽象主题角色类
// 主题角色类接口
public interface Subject {
 
// 添加订阅者
public void attach(Observer observer);
// 移除订阅者
public void detach(Observer observer);
// 发布者通知所有订阅者--推模式
public void nodifyObserversByPush(String newState);
}
具体主题角色类
//具体主题角色类
public class ConcreteSubject implements Subject{
 
    //用来保存注册的观察者对象
    private List<Observer> list = new ArrayList<Observer>();
    
    private String name = "SHQ";
    private int age = 27;
    
    public String getName() {
return name;
}
 
public int getAge() {
return age;
}
 
/**
     * 注册观察者对象
     * @param observer    观察者对象
     */
    @Override
    public void attach(Observer observer){
        list.add(observer);
        System.out.println("Attached an observer");
    }
    
    /**
     * 删除观察者对象
     * @param observer    观察者对象
     */
    @Override
    public void detach(Observer observer){
        list.remove(observer);
    }
    /**
     * 通知所有注册的观察者对象
     */
    @Override
    public void nodifyObserversByPush(String newState){
        for(Observer observer : list){
            observer.updateByPush(newState);
        }
    }    
}
抽象观察者角色类

//抽象观察者角色类
public interface Observer {
    /**
     * 更新接口--推模式
     * @param state    更新的状态
     */
    public void updateByPush(String state);
}
具体观察者角色类

// 具体观察者角色类
public class ConcreteObserver implements Observer {
 
    // 观察者的状态
    private String observerState;
    
    @Override
    public void updateByPush(String state) {
        /**
         * 更新观察者的状态，使其与目标的状态保持一致
         */
        observerState = state;
        System.out.println("状态为：" + observerState);
    }    
}
客户端类

//客户端类
public class Client {
    public static void main(String[] args) {
        //创建主题对象
        ConcreteSubject subject = new ConcreteSubject();
        //创建观察者对象
        Observer observer1 = new ConcreteObserver();       
        //将观察者对象登记到主题对象上
        subject.attach(observer1);
        //改变主题对象的状态--推模式
        subject.nodifyObserversByPush("new state");
    }
}
运行结果如下:

      在运行时，这个客户端首先创建了具体主题类的实例，以及一个观察者对象。然后，它调用主题对象的attach()方法，将这个观察者对象向主题对象登记，也就是将它加入到主题对象的聚集中去。

     这时，客户端调用主题的change()方法，改变了主题对象的内部状态。主题对象在状态发生变化时，调用超类的notifyObservers()方法，通知所有登记过的观察者对象。

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

推模型
　主题对象向观察者推送主题的详细信息，不管观察者是否需要，推送的信息通常是主题对象的全部或部分数据。

拉模型
     主题对象在通知观察者的时候，只传递少量信息。如果观察者需要更具体的信息，由观察者主动到主题对象中获取，相当于是观察者从主题对象中拉数据。一般这种模型的实现中，会把主题对象自身通过update()方法传递给观察者，这样在观察者需要获取数据的时候，就可以通过这个引用来获取了。

　　根据上面的描述，发现前面的例子就是典型的推模型，下面给出一个拉模型的实例。

拉模型的抽象观察者类

    拉模型通常都是把主题对象当做参数传递。

//抽象观察者角色类
public interface Observer {
    // 拉模式
    public void updateByPull(Subject subject);
}
拉模型的具体观察者类

// 具体观察者角色类
public class ConcreteObserver implements Observer {
 
    // 观察者的状态
    private String observerState;
    
@Override
public void updateByPull(Subject subject) {
observerState = ((ConcreteSubject)subject).getName();
System.out.println("状态为：" + observerState);
}
}
拉模型的抽象主题类

　拉模型的抽象主题类主要的改变是nodifyObservers()方法。在循环通知观察者的时候，也就是循环调用观察者的update()方法的时候，传入的参数不同了。

// 主题角色类接口
public interface Subject {
 
// 添加订阅者
public void attach(Observer observer);
// 移除订阅者
public void detach(Observer observer);
// 发布者通知所有订阅者--拉模式
public void nodifyObserversByPull();
}
拉模型的具体主题类

　　跟推模型相比，有一点变化，就是调用通知观察者的方法的时候，不需要传入参数了。

//具体主题角色类
public class ConcreteSubject implements Subject{
 
    //用来保存注册的观察者对象
    private List<Observer> list = new ArrayList<Observer>();
    
    private String name = "SHQ";
    private int age = 27;
    
    public String getName() {
return name;
}
 
public int getAge() {
return age;
}
 
/**
     * 注册观察者对象
     * @param observer    观察者对象
     */
    @Override
    public void attach(Observer observer){
        list.add(observer);
        System.out.println("Attached an observer");
    }
    
    /**
     * 删除观察者对象
     * @param observer    观察者对象
     */
    @Override
    public void detach(Observer observer){
        list.remove(observer);
    }
 
@Override
public void nodifyObserversByPull() {
        for(Observer observer : list){
            observer.updateByPull(this);
        }
}   
}
两种模式的比较

　 推模型是假定主题对象知道观察者需要的数据；而拉模型是主题对象不知道观察者具体需要什么数据，没有办法的情况下，干脆把自身传递给观察者，让观察者自己去按需要取值。

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

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

六、观察者模式的应用场景
    1、对一个对象状态的更新，需要其他对象同步更新，而且其他对象的数量动态可变。

    2、对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节。

七、观察者模式的优点
    1、Subject和Observer之间是松偶合的，分别可以各自独立改变(它把观察者与被观察者分离，并将二者间的关系通过抽象观察者和抽象被观察者联系在一起，当一方发生变化时不会影响另一方的执行，从而降低了程序的耦合。)。

    2、可以支持多种不同的具体观察者实现，有利于程序的扩展。

    3、观察者的数目是可变的，主题可以实现动态的增加或移除观察者对象。

    3、Subject在发送广播通知的时候，无须指定具体的Observer，Observer可以自己决定是否要订阅Subject的通知。

    4、遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。

    5、被观察者在自身状态发生变化时，会主动通知观察者，如果不是被观察者主动通知，那就需要观察者通过定时任务的方式来监控被观察者的状态是否发生变化，被观察者主动通知的方式要比观察者定时监控方式性能更高。

八、观察者模式的缺陷
    1、松偶合导致代码关系不明显，有时可能难以理解。

    2、如果一个Subject被大量Observer订阅的话，在广播通知的时候可能会有效率问题。（毕竟只是简单的遍历）。

    3、观察者模式是一种常用的触发机制，它形成一条触发链，依次对各个观察者的方法进行处理。但同时，这也算是观察者模式一个缺点，由于是链式触发，当观察者比较多的时候，性能问题是比较令人担忧的。并且，在链式结构中，比较容易出现循环引用的错误，造成系统假死。