观察者模式--行为型模式之三

1. 意图
定义对象间的一种一对多的依赖关系 ,当一个对象的状态发生改变时 , 所有依赖于它的对象
都得到通知并被自动更新。
2. 别名
依赖(Dependents), 发布-订阅(Publish-Subscribe)
3. 动机
       将一个系统分割成一系列相互协作的类有一个常见的副作用:需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合,因为这样降低了它们的可重用性。例如 , 许多图形用户界面工具箱将用户应用的界面表示与底下的应用数据分离[KP88,LVC89, P+88, WGM88]。定义应用数据的类和负责界面表示的类可以各自独立地复用。 当然它们也可一起工作。一个表格对象和一个柱状图对象可使用不同的表示形式描述同一个应用数据对象的信息。表格对象和柱状图对象互相并不知道对方的存在,这样使你可以根据需要单独复用表格或柱状图。但在这里它们表现的似乎互相知道。当用户改变表格中的信息时 ,柱状图能立即反映这一变化 , 反过来也是如此。

      这一行为意味着表格对象和柱状图对象都依赖于数据对象 , 因此数据对象的任何状态改变都应立即通知它们。同时也没有理由将依赖于该数据对象的对象的数目限定为两个, 对相同的数据可以有任意数目的不同用户界面。

O b s e r v e r模式描述了如何建立这种关系。这一模式中的关键对象是目标( s u b j e c t )和观察者( o b s e r v e r )。一个目标可以有任意数目的依赖它的观察者。一旦目标的状态发生改变 , 所有的观察者都得到通知。作为对这个通知的响应,每个观察者都将查询目标以使其状态与目标的状态同步。
      这种交互也称为发布-订阅 (publish-subscribe)。目标是通知的发布者。它发出通知时并不需知道谁是它的观察者。可以有任意数目的观察者订阅并接收通知。

4. 适用性
在以下任一情况下可以使用观察者模式 :
• 当一个抽象模型有两个方面 , 其中一个方面依赖于另一方面。将这二者封装在独立的对
象中以使它们可以各自独立地改变和复用。
• 当对一个对象的改变需要同时改变其它对象 , 而不知道具体有多少对象有待改变。
• 当一个对象必须通知其它对象,而它又不能假定其它对象是谁。换言之 , 你不希望这些
对象是紧密耦合的。
5. 结构

6. 参与者
• Subject(目标)
— 目标知道它的观察者。可以有任意多个观察者观察同一个目标。
— 提供注册和删除观察者对象的接口。
• Observer(观察者)
— 为那些在目标发生改变时需获得通知的对象定义一个更新接口。
• ConcreteSubject(具体目标)
— 将有关状态存入各 ConcreteObserver对象。
— 当它的状态发生改变时 , 向它的各个观察者发出通知。
• ConcreteObserver(具体观察者)
— 维护一个指向ConcreteSubject对象的引用。
— 存储有关状态,这些状态应与目标的状态保持一致。
— 实现Observer的更新接口以使自身状态与目标的状态保持一致。

7. 协作
• 当ConcreteSubject发生任何可能导致其观察者与其本身状态不一致的改变时,它将通知
它的各个观察者。
• 在得到一个具体目标的改变通知后 , ConcreteObserver 对象可向目标对象查询信息。
ConcreteObserver使用这些信息以使它的状态与目标对象的状态一致。
下面的交互图说明了一个目标对象和两个观察者之间的协作 :

注意发出改变请求的 O b s e r v e r对象并不立即更新 ,而是将其推迟到它从目标得到一个通知之后。Notify不总是由目标对象调用。它也可被一个观察者或其它对象调用。实现一节将讨论一些常用的变化。
8. 效果
Observer模式允许你独立的改变目标和观察者。你可以单独复用目标对象而无需同时复用其观察者, 反之亦然。它也使你可以在不改动目标和其他的观察者的前提下增加观察者。

转自《设计模式》