观察者设计模式

1.什么是观察者模式？

观察者是一个很常见的模式，又名依赖模式或发布-订阅模式。当一组对象依赖于另外一个对象的某个状态时，观察者模式就能很好地解决这个问题。观察者模式能解决这个需求：当对象间存在一对多的依赖关系，且一个对象的状态发生改变时，所有依赖于它的对象都将得到通知并且自动地完成某些工作。这就意味着观察者模式可以在单线程中，使某一对象，及时得知自身所依赖的状态的变化。

如果不采用观察者模式，我们往往可以在某个对象状态改变时，通过将行为硬编码来完成同样的功能，这适合于需求稳定的情况下，但需求又怎么可能稳定，当需求改变时，可能需要伴随着大量代码的改变。或者可以新开一个线程不停地监听依赖对象的状态，一旦监听到状态的改变，通知其他依赖于该对象的对象进行更新。但这将使系统的性能产生额外的负担。

接下来这个例子，可以很好地解释观察者模式。在某个电子商务网站中，你成为了它的会员，并订阅了其中的折扣信息。这时每当该网站有折扣信息时，你都会收到一封电子邮件。你再也不用主动地去网站上反复地刷新。当你经济拮据时，不想受到这些邮件的叨扰，取消订阅即可。

2.观察者模式的经典架构

想一想观察者有哪些？在某些情况下，可能是这样的：

• 不同类型的对象——有一系列对象需要在目标对象状态发生改变时得到通知，这些对象可能来自不同的类。
• 不同的接口——这些对象属于不同的类，往往都有不同的接口。

故我们要让所有的观察者实现同一个接口（IObserver），如果不这么做，当目标对象状态发生改变时，需要做一系列工作来处理不同类型的观察者。

为了让观察者和目标对象解耦，并且目标对象并不知道有哪些对象依赖于它，故观察者需要有一种方法向目标对象注册。所以目标对象应当有这两个方法：

• attach(IObserver observer)——将给定的观察者添加到目标的观察者列表当中。
• detach(IObserver observer)——顾名思义，将给定的观察者从列表中删除。

因为所有的目标对象都应该有这两个方法，可以将这两个方法抽象到 ISubject 接口中。

现在目标对象持有了观察者列表，当事件发生时（某个状态改变），即可通知这些观察者，为了更加简单，观察者对象应该有一个update方法来处理该事件。该方法应该抽象到 IObserver接口中。

目标类Subject可以实现一个inform方法，当需要通知时，该方法遍历观察者列表，并调用观察者的update方法即可。

到这里，观察者模式的架构呼之欲出了，如图1所示。

图1 观察者模式经典架构图

实际上对于Java来言，java.util包中已经准备了一套观察者模式的实现，java.util.Observer接口就相当于上图的IObserver。Java还给出了一罐java.util.Observable类，该类已经封装了添加观察者、删除观察者、通知观察者等方法，类似于上图的ISubject，不过由于Observable是一个类，当你的目标类继承了它就不能再继承其它类了，故在必要的时候还是需要自己实现ISubject接口。