观察者模式

观察者模式也叫发布/订阅模式,其定义如下:定义对象间一种一对多的依赖关系,使得每当一个对象改变状态,则所有依赖于它的对象都会得到通知并被自动更新。

我们先看看观察者模式的几个角色:

  • Subject被观察者:定义被观察者必须实现的职责,它必须能够动态的增加、取消观察者,它一般是抽象类或实现类,仅仅完成被观察者必须实现的职责,管理观察者和通知观察者。
  • Observer观察者:观察者接收到消息后,即进行更新(update)操作,对接收到的信息进行处理。
  • ConcreateSubject具体的被观察者:定义被观察者自己的业务逻辑,同时定义哪些事物被通知。
  • ConcreateObserver具体的观察者:每个观察者接收到通知后有不同的处理,各个观察者都有自己的处理逻辑。

下面看看通用代码示例: 

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

被观察者职责非常简单,定义谁能够观察,谁不能观察。

//具体被观察者
public class ConcreateSubject extends Subject{
    //具体的业务
    public void doSomething(){
        super.notifyObservers();  
    }
}

现在我们看到的是一个纯净的观察者,但它有很多变种,后面介绍:

//观察者
public interface observer{
    //更新方法
    public void update()
}
//实现具体观察者
public class ConcreateObserver implements Observer{
    //实现更新方法
    public void update(){
        //接收消息并处理  
    }
}
//定义个调用场景
public class Client{
    public static void main(String[] args){
        //创建一个被观察者
        ConcreateSubject subject = new ConcreateSubject();
        //定义一个观察者
        Observer obs = new ConcreateObserver();
        //观察者观察被观察者
        subject.addObserver(obs);
        //观察者开始活动了
        subject.doSomething();
    }
}

观察者模式的优点:

  • 观察者和被观察者是抽象耦合的。这样双方都很容易扩展。
  • 建立一套触发机制。将单一的职责串联成真实世界中复杂的逻辑关系。

缺点:

  • 需要考虑开发效率和运行效率的问题,一个被观察者和多个观察者就会使得开发和调试比较复杂,通知一般是顺序执行,这样容易出现阻塞的问题,应该考虑异步的方式。

应用场景:

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

观察者模式扩展:

  java提供了一个可扩展的父类,即java.util.observable,专门提供给需要暴露的类,比如被观察者类,这正符合我们的需要。

真实项目实践:

  为什么要说“真实”呢?因为刚才的代码只是标准的模式,在实际应用中常常会对它们做出改动,主要在三个方面:

  • 观察者和被观察者之间的消息传递

  被观察者改变状态通常会触发观察者的行为,同时传递一个消息给观察者,这是可以的,在实际应用中的做法是:观察者的update接收两个参数,一个是被观察者,一个是DTO(数据传输对象),DTO是一个纯洁的javabean,由被观察者生成,由观察者消费。如果考虑远程传输,DTO一般是json或xml。

  • 观察者响应方式

  观察者接收被观察者传递过来的消息,还要对它们做出处理,如果有多个被观察者,就要考虑性能问题了,如果观察者来不及响应,被观察者的执行时间会不会拉长?这就要考虑如何快速响应的问题了:一是使用多线程方式,无论是在观察者还是在被观察者启动线程,都可以显著提升性能,这就是所谓的异步架构;二是使用缓存技术,不管来什么,都先给你足够的空间缓存,这是比较好的方案,代价是开发难度更大,而且要做充分的压力测试,这就是所谓的同步架构。

  • 被观察者尽量自己做主

  被观察者的改变一定要通知观察者吗?不一定。设计时需要灵活考虑,以免加重观察者的处理逻辑,可以重载一个doSomething方法,决定是否通知观察者,而不是在消息到达观察者时才判断是否消费。

应用场景(包括但不限于):

  • 文件系统。比如在目录下新建一个文件,就通知观察者减少1kb的容量,“文件”是一个观察者,“目录管理器”则是被观察者。
  • 猫鼠游戏。
  • ATM取钱。当输入密码错误多次、银行卡被吞等事件发生时,会触发哪些事件呢?一是摄像头抓拍,二是通知监控人员处理,三是恢复屏幕为初始状态。这都是通过观察者模式完成。
  • 广播收音机
原文地址:https://www.cnblogs.com/loveBolin/p/9740143.html