4.Observable类的分析
Observable#changed属性的初始值为false，这很容易理解，不再详细陈述。细心的读者可能会注意到跟changed属性有关的两个方法setChanged()和clearChanged()，它们的修饰符都是protected。想强调的是，是protected，而不是public。但这样是否有其必要性和合理性？答案是肯定的。在前面的分析中，我已经提到，setChanged()方法是设置changed的唯一入口，它的修饰符定义为protected，就意味着通过定义Observable的对象，再设置changed属性将变得不可能。从这个意义上说，要想应用observer
设计模式，必须继承Observable类方可。关于这一点，下文还会提及。但是，为什么不能定义成public？这似乎难以理解。因为定义成public，我们不就可以很方便地设置changed属性的值吗？为了弄清楚这个问题，我们还是看一下Observable里的相关的代码：
//……省略……
public void notifyObservers(Object arg) {
//……省略……
for (int i = arrLocal.length-1; i>=0; i--)
((Observer)arrLocal[i]).update(this, arg);
}
这段代码表达的意思是说找出所有已注册的Observer，再逐个进行“通知”，通过调用Observer#update(Observable,Object)方法进行通知。我们看到，update 第一个参数是this，我们同时还必须注意到，这段代码是Observable类里的代码。这就相当于是在一再强调，发出“通知”的，必须是observable自己（Observable类或者其派生类），其它任何类都不行。这就意味着我们的observable类继承Observable类是必要的，因为如果不继承，而采用组合的话，将无法保证能传递好this。换句话说，采用组合的方式使用Observable类，将变得几乎没有任何意义。同时，修饰符定义为protected，可以确保是在Obsrvable里进行触发通知的，不会在其它任何地方进行通知，这显得内敛性很强。如果将setChanged（）修饰符定义为public，将无法保证正确“传递this”的硬性要求，这不符合“只有observalbe才能直接或间接通知observer”这一observable设计模式的硬性要求。由此我们可见一斑，jdk的很多理念的思想性是多么的强。
5.解决使用observer设计模式存在的困难
借助adapter设计模式（详见本人发表的adapter设计模式相关文章）和
java支持多接口特性基本可以解决“多继承”问题。基本思想是结合继承/实现和组合来达到效果。在上面的分析中，我们已经知道，Observable类必须继承使用，不能组合使用，因此我们只需要将需扮演成observerable角色的类装扮成adapter角色，将该类原继承的类装扮成adaptee角色即可。示例代码如下：
//欲充当observable角色的类的原来的代码：
public class MyObject extends BaseObject {
public MyObject() {
public void method1(){}
}
}
//充当observable角色后的代码：
public class MyObject extends Observable {
private BaseObject baseObject = null;
public MyObject(BaseObject baseObject) {
this.baseObject = baseObject;
}
}
6. 注意事项：
如果上例中的BaseObject也用到需要传递“this”的方法，那么上面的组合使用方法将有可能失效。这种情况是最糟糕的情况。此时可以考虑在BaseObject类这些“瓶颈”地方尽量采用接口代替类（包括抽象类）来解决。
