29
§ System.out.println("猫叫了");
30
§
this
.setChanged();
31
§
this
.notifyObservers();
32
§}
33
§}
34
§
35
§§
class
Mouse
extends
Observable
implements
Observer{
//老鼠观察猫，猫是观察者,对于人,老鼠是被观察者
37
§§
public
void
update(Observable arg0, Object arg1) {
38
§
// TODO Auto-generated method stub
39
§
System.out.println("猫叫了，老鼠跑了");
40
§
this
.setChanged();
41
§
this
.notifyObservers();
42
§}
44
§}
46
§§
class
Man
implements
Observer{
//人观察老鼠,人是观察者
48
§§
public
void
update(Observable arg0, Object arg1) {
49
§
// TODO Auto-generated method stub
50
§
System.out.println("老鼠跑了,人惊醒了");
51
§}
52
§}
我认为在 JDK 中这个 Observer 模式的实现，对于一般的 Observer 模式的应用，已经是非常
的足够了的。但是一方面它用一个类来实现了 Subject，另一方面它使用 Vector 来保存
Subject 对于 Observer 的引用，这虽然简化了编程的过程，但会限制它在一些需要更为灵活，
复杂的设计中的应用，有时候（虽然这种情况不多），我们还不得不重新编写新的 Subject 对
象和额外的 Manager
对象来实现更为复杂的 Observer 模式的应用。
小结：
观察者模式的应用场景：
1、 对一个对象状态的更新，需要其他对象同步更新，而且其他对象的数量动态可变。
2、 对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节。
观察者模式的优点：
1、 Subject 和 Observer 之间是松偶合的，分别可以各自独立改变。
2、 Subject 在发送广播通知的时候，无须指定具体的 Observer，Observer 可以自己决定
是否要订阅 Subject 的通知。
3、 遵守大部分 GRASP 原则和常用设计原则，高内聚、低偶合。
观察者模式的缺陷：
1、 松偶合导致代码关系不明显，有时可能难以理解。(废话)
2、 如果一个 Subject 被大量 Observer 订阅的话，在广播通知的时候可能会有效率问题。
（毕竟只是简单的遍历）