观察者模式详解-优快云博客

本文详细介绍了观察者模式的定义、类图及代码实现，并探讨了其优缺点、使用场景及注意事项。此外，还讨论了模式在Java中的应用及项目中的实际改造情况。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1.定义

观察者模式（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.（定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。）

2.类图

这里写图片描述

3.代码

/**
* 被观察者
*/
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();
    }
}

4.优点

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

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

建立一套触发机制

根据单一职责原则，每个类的职责是单一的，那么怎么把各个单一的职责串联成真实世界的复杂的逻辑关系呢？比如，我们去打猎，打死了一只母鹿，母鹿有三个幼崽，因失去了母鹿而饿死，尸体又被两只秃鹰争抢，因分配不均，秃鹰开始斗殴，然后羸弱的秃鹰死掉，生存下来的秃鹰，则因此扩大了地盘……这就是一个触发机制，形成了一个触发链。观察者模式可以完美地实现这里的链条形式。

5.缺点

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

6.使用场景

关联行为场景。需要注意的是，关联行为是可拆分的，而不是“组合”关系。
事件多级触发场景。
跨系统的消息交换场景，如消息队列的处理机制。

7.注意事项

使用观察者模式也有以下两个重点问题要解决。

广播链的问题

如果你做过数据库的触发器，你就应该知道有一个触发器链的问题，比如表A上写了一个触发器，内容是一个字段更新后更新表B的一条数据，而表B上也有个触发器，要更新表C，表C也有触发器……完蛋了，这个数据库基本上就毁掉了！我们的观察者模式也是一样的问题，一个观察者可以有双重身份，既是观察者，也是被观察者，这没什么问题呀，但是链一旦建立，这个逻辑就比较复杂，可维护性非常差，根据经验建议，在一个观察者模式中最多出现一个对象既是观察者也是被观察者，也就是说消息最多转发一次（传递两次），这还是比较好控制的。

注意它和责任链模式的最大区别就是观察者广播链在传播的过程中消息是随时更改的，它是由相邻的两个节点协商的消息结构；而责任链模式在消息传递过程中基本上保持消息不可变，如果要改变，也只是在原有的消息上进行修正。

异步处理问题

这个EJB是一个非常好的例子，被观察者发生动作了，观察者要做出回应，如果观察者比较多，而且处理时间比较长怎么办？那就用异步呗，异步处理就要考虑线程安全和队列的问题，这个大家有时间看看Message Queue，就会有更深的了解。

8.扩展

8.1 Java世界中的观察者模式
Java从一开始诞生就提供了一个可扩展的父类，即java.util.Observable，这个类就是为那些“暴露狂”准备的，他们老是喜欢把自己的状态变更让别人去欣赏，去触发，这正符合了我们现在的要求，要把韩非子的所有活动都暴露出去，并且想暴露给谁就暴露给谁。我们打开Java的帮助文件看看，查找一下Observable是不是已经有这个类了？JDK中提供了:java.util.Observable实现类和java.util.Observer接口，也就是说我们上面写的那个例子中的Observable接口可以改换成java.util.Observale实现类了，如图所示
这里写图片描述

/**
* 优化后的被观察者
*/
public class HanFeiZi extends Observable,IHanFeiZi{
    //韩非子要吃饭了
    public void haveBreakfast(){
        System.out.println("韩非子：开始吃饭了...");
        //通知所有的观察者
        super.setChanged();
        super.notifyObservers("韩非子在吃饭");
    }
    //韩非子开始娱乐了
    public void haveFun(){
        System.out.println("韩非子：开始娱乐了...");
        super.setChanged();
        this.notifyObservers("韩非子在娱乐");
    }
}

/**
 * 优化后的观察者
*/
public class LiSi implements Observer{
    //首先李斯是个观察者，一旦韩非子有活动，他就知道，他就要向老板汇报
    public void update(Observable observable,Object obj){
        System.out.println("李斯：观察到韩非子活动，开始向老板汇报了...");
        this.reportToQinShiHuang(obj.toString());
        System.out.println("李斯：汇报完毕...\n");
    }
    //汇报给秦始皇
    private void reportToQinShiHuang(String reportContext){
        System.out.println("李斯：报告，秦老板！韩非子有活动了--->"+reportContext);
    }
}

8.2 项目中真实的观察者模式
在系统设计中会对观察者模式进行改造或改装，主要在以下3个方面。

观察者和被观察者之间的消息沟通

被观察者状态改变会触发观察者的一个行为，同时会传递一个消息给观察者，这是正确的，在实际中一般的做法是：观察者中的update方法接受两个参数，一个是被观察者，一个是DTO（Data Transfer Object，据传输对象），DTO一般是一个纯洁的JavaBean,由被观察者生成，由观察者消费。

当然，如果考虑到远程传输，一般消息是以XML格式传递。

观察者响应方式

我们这样来想一个问题，观察者是一个比较复杂的逻辑，它要接受被观察者传递过来的信息，同时还要对他们进行逻辑处理，在一个观察者多个被观察者的情况下，性能就需要提到日程上来考虑了，为什么呢？如果观察者来不及响应，被观察者的执行时间是不是也会被拉长？那现在的问题就是：观察者如何快速响应？有两个办法：一是采用多线程技术，甭管是被观察者启动线程还是观察者启动线程，都可以明显地提高系统性能，这也就是大家通常所说的异步架构；二是缓存技术，甭管你谁来，我已经准备了足够的资源给你了，我保证快速响应，这当然也是一种比较好方案，代价就是开发难度很大，而且压力测试要做的足够充分，这种方案也就是大家说的同步架构。

被观察者尽量自己做主

这是什么意思呢？被观察者的状态改变是否一定要通知观察者呢？不一定吧，在设计的时候要灵活考虑，否则会加重观察者的处理逻辑，一般是这样做的，对被观察者的业务逻辑doSomething方法实现重载，如增加一个doSomething(boolean isNotifyObs)方法，决定是否通知观察者，而不是在消息到达观察者时才判断是否要消费

8.3 订阅发布模型
观察者模式也叫做发布/订阅模型（Publish/Subscribe），在EJB中有3个类型的Bean: Session Bean、Entity Bean和MessageDriven Bean，我们这里来说一下MessageDriven Bean（一般简称为MDB），消息驱动Bean，消息的发布者（Provider）发布一个消息，也就是一个消息驱动Bean，通过EJB容器（一般是Message Queue消息队列）通知订阅者做出回应，从原理上看很简单，就是观察者模式的升级版，或者说是观察则模式的BOSS版。