这个“观察者模式的实战范例”标题，大家看起来一头雾水很不理解吧，现在lola就给大家详细介绍一下。
下面简单说下观察者模式是个什么。所谓“观察者”，就是观众，围观群众。但只有围观群众还构不成观察者模式，还需要有“被观察者”。观察者模式由“被观察者”和“观察者”共同构成。一个“被观察者”可能会有0到n个“观察者”。
在我们社区中“被观察者”可以是“博客”、“用户”、“组件设计”、“讨论”、“留言”等等。“观察者”则是“积分”、“动态”、“邮件”、“站内信”、“短信”等等。举个例子：当用户发表一篇博客，各个关注者将会被通知，积分系统得知后会给用户做加分，动态系统会增加动态信息，其他系统也会根据自己的需要做一些处理。
其实观察者模式与java中的事件机制是非常相似的。当事件发生时，所有的监听器将会得到事件的信息，做自己分内的工作。所以“被观察者”我们可以认为是事件源EventSource，“观察者”就是监听器Listener。一个事件源可以有多个动作叫做Action，事件源发起动作称之为事件Event。
当事件源EventSource发生一个动作Action时，产生一个事件Event。所有的关注者Listener将的到这个Event，并根据Event中的信息，来完成自己要做的事情。这就是整个事件机制也就是观察者模式的大体过程。
在实际的程序中，我们可能会有几个点需要解决一下。一个是，动作发生时，如何产生一个事件？另一个是，监听器如何关注事件并被通知到？对于第一个问题，我们只需要一个点火装置在动作发生时fire一下。解决第二个问题，我们需要一个可以容纳足够“观察者”的容器，就好像观看演出的剧场观众席。当事件发生时，依次通知这些“观察者”。
那么整体的结构应该是这样的：
通常情况下，监听机制有这些东西就可以建立了。具体的监听器，只要实现Listener接口，然后添加到事件源中就可以对事件源所发生的事件进行观察了。不过我觉得可能这样看起来不是很舒服，因为写程序时，我们应该尽可能让业务服务中少一些不相干的东西。比如上面EventSource里的listeners和一些fireEvent这样的方法。所以改造一下成下面这种形式，可以让程序看起来干净一些。
另外获得一个好处：经过这一步改造后，事件源与“事件类”、“监听器类”隔绝了，我们在系统中使用这种机制变得更加方便了。
在实际的社区应用中事件机制就是基于这种关系组织建立起来的。为了更加便于开发和扩展，在应用时又做了一些扩充。
