事件驱动模型

 下面简单说下观察者模式是个什么。所谓“观察者”，就是观众，围观群众。但只有围观群众还构不成观察者模式，还需要有“被观察者”。观察者模式由“被观察者”和“观察者”共同构成。一个“被观察者”可能会有0到n个“观察者”。
    在我们社区中“被观察者”可以是“博客”、“用户”、“组件设计”、“讨论”、“留言”等等。“观察者”则是“积分”、“动态”、“邮件”、“站内信”、“短信”等等。举个例子：当用户发表一篇博客，各个关注者将会被通知，积分系统得知后会给用户做加分，动态系统会增加动态信息，其他系统也会根据自己的需要做一些处理。
    其实观察者模式与java中的事件机制是非常相似的。当事件发生时，所有的监听器将会得到事件的信息，做自己分内的工作。所以“被观察者”我们可以认为是事件源EventSource，“观察者”就是监听器Listener。一个事件源可以有多个动作叫做Action，事件源发起动作称之为事件Event。
    当事件源EventSource发生一个动作Action时，产生一个事件Event。所有的关注者Listener将的到这个Event，并根据Event中的信息，来完成自己要做的事情。这就是整个事件机制也就是观察者模式的大体过程。
    在实际的程序中，我们可能会有几个点需要解决一下。一个是，动作发生时，如何产生一个事件？另一个是，监听器如何关注事件并被通知到？对于第一个问题，我们只需要一个点火装置在动作发生时fire一下。解决第二个问题，我们需要一个可以容纳足够“观察者”的容器，就好像观看演出的剧场观众席。当事件发生时，依次通知这些“观察者”。

 

  那么整体的结构应该是这样的：

 

 

通常情况下，监听机制有这些东西就可以建立了。具体的监听器，只要实现Listener接口，然后添加到事件源中就可以对事件源所发生的事件进行观察了。不过我觉得可能这样看起来不是很舒服，因为写程序时，我们应该尽可能让业务服务中少一些不相干的东西。比如上面EventSource里的listeners和一些fireEvent这样的方法。所以改造一下成下面这种形式，可以让程序看起来干净一些。

    另外获得一个好处：经过这一步改造后，事件源与“事件类”、“监听器类”隔绝了，我们在系统中使用这种机制变得更加方便了。
    在实际的社区应用中事件机制就是基于这种关系组织建立起来的。为了更加便于开发和扩展，在应用时又做了一些扩充。
    由于社区中需要关注的事件并不是很多，一个事件管理器已经足够使用，我们可以采用使用同一套管理器管理多类事件并分发给相关监听者的方式。
    采用这种方式，首先要区分出事件的来源是什么，以便发生事件时通知相关的监听器。因此，增加了一个事件来源标识的枚举，为了区分事件来源，是博客、微博、讨论还是其他什么。

 

 

总体结构如下图：

 

 

（PS：附件里是我测试的代码，有兴趣的朋友可以看一下。看这部分内容的时候，建议对照java源码中Swing中的处理。）

图片弄不过来，看一下原文。 http://www.360doc.com/content/13/0926/19/14033216_317287125.shtml