观察者模式

观察者模式（Observer Pattern）也叫做发布订阅模式（Publish/subscribe）,它是一个在项 目中经常使用的模式，其定义如下：

Define a one-to-many dependency between objects so that when one object changes state,all its dependents are notified and updated automatically.（定义对象间一种一对多的依赖关系，使得每 当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。）

观察者模式的通用类图，如图所示。

角色解释：

Subject被观察者

定义被观察者必须实现的职责，它必须能够动态地增加、取消观察者。它一般是抽象类 或者是实现类，仅仅完成作为被观察者必须实现的职责：管理观察者并通知观察者。

 

Observer观察者

观察者接收到消息后，即进行update（更新方法）操作，对接收到的信息进行处理。

 

ConcreteSubject具体的被观察者

定义被观察者自己的业务逻辑，同时定义对哪些事件进行通知。

 

ConcreteObserver具体的观察者

每个观察在接收到消息后的处理反应是不同，各个观察者有自己的处理逻辑。

被观察者

public abstract class Subject { 
    //定义一个观察者数组 
    private Vector<Observer> obsVector = new Vector<Observer>(); 
    //增加一个观察者 
    public void addObserver(Observer o){
        this.obsVector.add(o);
    } 
    //删除一个观察者 
    public void delObserver(Observer o){
        this.obsVector.remove(o);
    } 
    //通知所有观察者 
    public void notifyObservers(){ 
        for(Observer o:this.obsVector){
            o.update();
        }
    }
}

//具体被观察者

public class ConcreteSubject extends Subject { 
    //具体的业务 
    public void doSomething(){ 
        /* 
         * do something 
         */ 
        super.notifyObservers();
    }
}

//观察者

public interface Observer { 
    //更新方法 
    public void update();
}

//具体观察者

public class ConcreteObserver implements Observer { 
    //实现更新方法 
    public void update() {
        System.out.println("接收到信息，并进行处理！");
    }
}

//场景类 

public class Client { 
    public static void main(String[] args) { 
        //创建一个被观察者 
        ConcreteSubject subject = new ConcreteSubject(); 
        //定义一个观察者 
        Observer obs= new ConcreteObserver();
        //观察者观察被观察者
        subject.addObserver(obs); 
        //观察者开始活动了
        subject.doSomething();
    }
}

 优点

观察者和被观察者之间是抽象耦合

如此设计，则不管是增加观察者还是被观察者都非常容易扩展，而且在Java中都已经实现的抽象层级的定义，在系统扩展方面更是得心应手。

建立一套触发机制

根据单一职责原则，每个类的职责是单一的，那么怎么把各个单一的职责串联成真实世界的复杂的逻辑关系呢？观察者模式可以完美地实现链条形式。

 

缺点

观察者模式需要考虑一下开发效率和运行效率问题，一个被观察者，多个观察者，开发 和调试就会比较复杂，而且在Java中消息的通知默认是顺序执行，一个观察者卡壳，会影响 整体的执行效率。在这种情况下，一般考虑采用异步的方式。

多级触发时的效率更是让人担忧，大家在设计时注意考虑。

 

使用场景

关联行为场景。

需要注意的是，关联行为是可拆分的，而不是“组合”关系。

事件多级触发场景。

跨系统的消息交换场景，如消息队列的处理机制。