Head First设计模式 观察者模式

定义

观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
实现观察者模式的方法不只一种，但是以包含Subject与Observe接口的类设计的做法最常见。

设计原则

1. 为了交互对象之间的松耦合设计而努力。

错误示例

观察者模式的解释

观察者可以移除和增加。

类图说明

问：这和一对多的关系有何联系？
答：利用观察者模式，主题是具有状态的对象，并且可以控制这些状态。也就是说，有“一个”具有状态的主题。另一方面，观察者使用这些状态，虽然这些状态并不属于他们。有许多的观察者，依赖主题来告诉他们状态何时改变了。这就产生一个关系：“一个”主题对“多个”观察者的关系。
问：其间的依赖是如何产生的？
答：因为主题是真正拥有数据的人，观察者是主题的依赖者，在数据变化时更新，这样比起让许多对象控制同一份数据来，可以得到更干净的OO设计。

松耦合的威力

当两个对象之间松耦合，它们依然可以交互，但是不太清楚彼此的细节。观察者模式提供了一种对象设计，让主题和观察者之间松耦合。
因为主题唯一依赖的东西是一个实现Observe接口的对象列表，所以我们可以随时增加观察者。同样的，也可以在任何时候删除某些观察者。
改变主题或观察者其中一方，并不会影响另一方，因为两者是松耦合的，所以只要他们之间的接口仍被遵守，我们就可以自由地改变他们.

松耦合的设计之所以能让我们建立有弹性的OO系统，能够应对变化，是因为对象之间的互相依赖降到了最低。

设计气象站

虽然，某些时候可以利用Java内置的支持，但是有许多时候，自己建立这一切会更有弹性（况且建立这一切并不是很麻烦）。
java.util包内包含最基本的Observer接口与Observable类。

推(push)数据给观察者；观察者从可观察者对象中“拉”(pull)数据。

setChanged()方法

setChanged()方法用来标记状态已经改变的事实，好让notifyObservers()知道当它被调用时应该更新观察者。如果调用notifyObservers()之前没有先调用setChanged()，观察者就“不会”被通知。
这样做有其必要性。setChanged()方法可以让你在更新观察者时，有更多的弹性，你可以更适当地通知观察者。

Java.util.Observable的黑暗面

首先，因为Observable是一个“类”，你必须设计一个类继承它。如果某类想同时具有Observable类和另一个超类的行为，就会陷入两难，毕竟Java不支持多重继承。这限制了Observable的复用潜力（而增加复用潜力不正是我们使用模式最原始的动机吗？）。
如果你看看Observable API，你会发现setChanged()方法被保护起来了(被定义成protected)。那又怎么样呢？这意味着：除非你继承自Observable，否则你无法创建Observable实例并组合到你自己的对象中来。这个设计违反了第二个设计原则：“多用组合，少用继承”。

要点

1. 观察者模式定义了对象之间的一对多关系。
2. 主题（也就是可观察者）用一个共同的接口来更新观察者。
3. 观察者和可观察者之间用松耦合方式结合(loosecoupling)，可观察者不知道观察者的细节，只知道观察者实现了观察者接口。
4. 使用此模式时，你也一从被观察者处推(push)或拉(pull)数据（然而，推的方式被认为更“正确”）。
5. 有多个观察者时，不可以依赖特定的通知次序。
6. Java有多种观察者模式的实现，包括了通用的java.util.Observable。
7. 要注意java.util.Observable实现上所带来的一些问题。
8. 如果有必要的话，可以实现自己的Observable，这并不难，不要害怕。
9. Swing大量使用观察者模式，许多GUI框架也是如此。
   10.此模式也被应用在许多地方，例如：JavaBeans、RMI。

挑战设计原则

1. 找出程序中会变化的方面，然后将其和固定不变的方面相分离。在观察者模式中，会改变的是主题的状态，以及观察者的数目和类型。用这个模式，你可以改变依赖于主题状态的对象，却不必改变主题。这就叫提前规划！
2. 针对接口编程，不针对实现编程。主题与观察者都使用接口，观察者利用主题的接口向主题注册，而主题利用观察者接口通知观察者。这样可以让两者之间运作正常，同时又具有松耦合的优点。
3. 多用组合，少用继承。观察者模式利用“组合”将许多观察者组合进主题中。对象之间的这种关系不是通过继承产生的，而是在运行时利用组合的方式产生的。