观察者模式学习

观察者模式(Observer Design Pattern)也被称为发布订阅模式(Publish-Subscribe Design Pattern)。在 GoF 的《设计模式》一书中,它的定义是这样的:
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
中文翻译:在对象之间定义一个一对多的依赖,当一个对象状态改变的时候,所有依赖的对象都会自动收到通知。
一般情况下,被依赖的对象叫作被观察者(Observable),依赖的对象叫作观察者(Observer)。不过,在实际的项目开发中,这两种对象的称呼是比较灵活的,有各种不同的叫法,比如:Subject-Observer、Publisher-Subscriber、Producer-Consumer、EventEmitter-EventListener、Dispatcher-Listener。不管怎么称呼,只要应用场景符合刚刚给出的定义,都可以看作观察者模式。

从定义中可以知道,观察者主要应用于通知的场景,并且通知的对象可能需要频繁的改变。它可以解耦被观察者与观察者。
观察者模式的应用场景非常广泛,小到代码层面的解耦,大到架构层面的系统解耦,再或者一些产品的设计思路,都有这种模式的影子,比如,邮件订阅、RSS Feeds,本质上都是观察者模式。

经典实现方式
我们先来看其中最经典的一种实现方式。这也是在讲到这种模式的时候,很多书籍或资料给出的最常见的实现方式。具体的代码如下所示:

public interface Subject {
  void registerObserver(Observer observer);
  void removeObserver(Observer observer);
  void notifyObservers(Message message);
}

public interface Observer {
  void update(Message message);
}

public class ConcreteSubject implements Subject {
  private List<Observer> observers = new ArrayList<Observer>();

  @Override
  public void registerObserver(Observer observer) {
    observers.add(observer);
  }

  @Override
  public void removeObserver(Observer observer) {
    observers.remove(observer);
  }

  @Override
  public void notifyObservers(Message message) {
    for (Observer observer : observers) {
      observer.update(message);
    }
  }

}

public class ConcreteObserverOne implements Observer {
  @Override
  public void update(Message message) {
    //TODO: 获取消息通知,执行自己的逻辑...
    System.out.println("ConcreteObserverOne is notified.");
  }
}

public class ConcreteObserverTwo implements Observer {
  @Override
  public void update(Message message) {
    //TODO: 获取消息通知,执行自己的逻辑...
    System.out.println("ConcreteObserverTwo is notified.");
  }
}

public class Demo {
  public static void main(String[] args) {
    ConcreteSubject subject = new ConcreteSubject();
    subject.registerObserver(new ConcreteObserverOne());
    subject.registerObserver(new ConcreteObserverTwo());
    subject.notifyObservers(new Message());
  }
}

这个例子很好理解:

它具有一个被观察者接口(Subject)和一个观察者接口(Observer);
所有具体的被观察者都需要实现Subject接口,即所有的被观察者都具有注册观察者方法(registerObserver)、删除观察者方法(removeObserver)、通知观察者方法(notifyObservers);
所有具体的观察者都需要实现Observer接口,即所有的观察者都具有执行通知逻辑的方法(update);
在被观察者中通过一个List来保存所有注册的观察者,在需要时通过遍历List来通知所有的观察者。

但上面的代码算是观察者模式的“模板代码”,只能反映大体的设计思路。在真实的软件开发中,并不需要照搬上面的模板代码。而且Java中也有一些第三方框架供我们使用,它们提供了实现观察者模式的骨架代码,我们可以基于此框架,非常容易地在自己的业务场景中实现观察者模式,不需要从零开始开发,如Guava 的EventBus、Spring Event等。

观察者模式的实现原理分析

如何通知观察者?
我们看到,被观察者需要通知每一个观察者,所以上面示例中被观察者通过一个List来保存了观察者,然后通过遍历List来实现通知每一个观察者。当然通过其他的容器也可以实现,比如Guava的EventBus就是用ConcurrentMap来存储的观察者信息的。
还有被观察者中保存的是观察者的接口,并不知道观察者的细节,即被观察者和观察者之间用松耦合方式结合(loosecoupling),符合“为交互对象之间的松耦合设计而努力”的设计原则。
在上面示例中是被观察者主动将消息推送到观察者中的,这种方式被称为推(push)。还有一种称为拉(pull)的方式,即被观察者通知观察者后,观察者再从被观察者中获取所需的数据。pull方式的前提条件是,被观察者需要提供对外获取数据的接口,同时观察者中需要能获取到被观察者对象。显然,pull方式使被观察者与观察者联系更紧密了,这不一定是一个好的现象

如何更具有复用性?
被观察者需要提供注册、通知等通用接口,其实这些操作和我们实际业务关系不大,可以考虑抽取出来。此时有两种可以考虑的方式,
一种是继承方式,将通用的操作都抽取到父类中,所有的被观察者只需要继承父类就可以具有注册、通知等操作的实现,JDK1.0中的观察者模式就是这样做的,它提供了Observable类用于给被观察者继承。
一种是组合方式,将通用的操作都抽取到其他类中,被观察者通过委托该类来实现注册、通知等通用操作。如果使用Guava的EventBus,就是通过组合EventBus类来实现的。
我们都知道组合的方式优于继承,因为继承有诸多限制,比如单继承。所以一般都推荐使用组合的方式,目前常用的第三方框架采用的都是组合的方式。

同步通知与异步通知
在通知观察者的方式上我们可以有两种方式,同步阻塞的实现方式和异步非阻塞的实现方式。
同步阻塞的实现方式
观察者和被观察者代码在同一个线程内执行,被观察者一直阻塞,直到所有的观察者代码都执行完成之后,才执行后续的代码。
上面讲到的用户注册的例子就是同步阻塞方式,register() 函数依次调用执行每个观察者的 handleRegSuccess() 函数,等到都执行完成之后,才会返回结果给客户端。
异步非阻塞的实现方式
如果注册接口是一个调用比较频繁的接口,对性能非常敏感,希望接口的响应时间尽可能短,那我们可以将同步阻塞的实现方式改为异步非阻塞的实现方式,以此来减少响应时间。
实现异步非阻塞的方式我们既可以自己手动创建线程来实现,也可以采用第三方框架提供的异步执行功能,如如Guava 的EventBus、Spring Event等。
跨进程间的调用
我们一般所介绍的观察者模式都是指在一个进程间(通常就是指同一个项目代码)进行的通知,但其实观察者模式也可以应用于进程间,比如如果用户注册成功之后,我们需要发送用户信息给大数据征信系统,而大数据征信系统是一个独立的系统,跟它之间的交互是跨不同进程的。
要实现跨进程的观察者模式,其实就是要实现进程间的通讯,这个我们就比较熟悉了,常用的就是:

RPC 接口调用的方式。
消息队列的方式。(采用消息队列的发布-订阅模式)

消息队列方式相对于RPC方式来说,被观察者和观察者解耦更加彻底,两部分的耦合更小,因为被观察者完全不感知观察者,同理,观察者也完全不感知被观察者。不过弊端就是需要引入一个新的系统(消息队列),增加了维护成本。

你可能感兴趣的:(学习,观察者模式,学习)