来自观察者模式中两个成员的经典对话

二 究竟是要“推我”还是“拉你”？

  听完观察者模式两个成员的经典对话之后，我想大家对观察者模式会有了更深刻的印象。究竟是要“推我”还是“拉你”，从上面的对话我们很容易下这样结论：完全取决于被观察者对象的复杂性，如果被观察对象比较复杂，并且观察者需要有一个提示，那么推模型是合适的。如果被观察的对象比较简单，那么拉模型就很合适。

三 观察者模式在Java编程中的应用（重点学习JavaBeans事件模型）

  学习设计模式的过程中，一直都有这种感受，看JDK的API甚至是源代码，你会发现比已经更有条理性了，更好理解了，可以说要想研究JDK源代码（我想别的源代码也一样）必须很好地理解了设计模式。有两种方式来查看观察者模式的细节，第一种办法是了解定义在java.util的Observer和Observable类。第二种方法是研究注册事件监听器的JavaBeans组件模型。在创建JavaBeans事件模型之前，Observer和Observable类就描述了观察者模式的实现。换句话说，自从Java平台1.0版本，这些类就已经存在了。由于这些类在设计上并没有什么技术错误，因此一直沿用下来了。这些类现在还可以用于实现观察者模式，但是用的更多的是JavaBeans事件模型，我也想花多点时间研究下在这方面的应用，这会对我们在GUI编程方面上有更多的帮助。

  较喜欢这样的划分事件处理模型中的对象：事件对象，事件制造者对象和事件接收者对象。其中，某一个对象是事件的制造者，其余对象是事件的接收者;而事件对象本身则装了有关事件的信息。当事件制造者的内部状态发生了变化时，会根据需要创建一个代表其状变化的事件对象，并将它传给所有登记过的事件接收者对象。对于这种机制，我想大家在听了上面的对话后应该可以很自然地想到这就是建立在观察者模式的基础之上的。其实，从网上资料得知Java1.0的事件处理机制是建立在责任链模式的基础上的（呵呵，写这篇文章的时候还没有学到这种设计模式呢～～）在学习这种事件机制之前，我们先来看看MVC中的Model- View，它们作为MVC模式的一部分，就是Subject和Obverser的关系，因而，模型的改变必须要在UI对象中体现出来。Swing使用了 JavaBeans的事件模型来实现这种通知机制。根据前面Subject和Obverserr的对话，有两种实现办法，一是仅仅通知事件监听者状态改变了，然后由事件监听者向模型提取必要的状态信息。这种机制对于事件频繁的组件很有效。另外的一种办法是模型向监听者发送包含了已改变的状态信息的通知给 UI。这两种方法根据其优劣被分别是现在不同的组件中。比如在JScollBar中使用的是第一种方法，在JTable中使用的是第二种方法。顺便提下 JTable，我们在基于C/S架构的应用中如果要从数据库中取出一批数据然后把它大列表中显示，这时候会用到大量的JTable，到时候我们就可以更好地理解这种机制了。

   回到事件监听机制，对Model而言，为了能够支持多个View，它并不知道具体的每一个View。它维护一个对其数据感兴趣的Obverser的列表。调用addXXXListener()方法增加一个监听器，调用removeXXXListener()方法删除一个监听器，这两个方法都要需要一个相应类型的监听器类型。所有的AWT组件都是java.awt.Component的子类，它们都从Component类继承了各个 addXXXListener()方法。