Listener和Observer有什么本质区别吗?

mediator和observer是竞争的模式，前者将调用通讯封装在内部，而后者是不封装调用者和被调用者的通讯，而是直接是被调用者。

MVC模式中的Controller才是真正Mediator，前后端调用都被其封装。

Listener和observer基本差不多，观察者好像是用眼睛看，而监听者好像是用耳朵听，两者本质都是监测某个事件是否发生，监测手段不同而已。

观察者模式经常和事件放在一起，事件是其显著特征，谈到事件有两个角色：生产者和消费者，类似观察者和被观察者，两者看问题的角度不同而已。
[该贴被banq于2012-12-03 16:19修改过]

从封装变化的角度去看：
Observer模式的场景中，变化的是观察者, 通过addListener()和removeListener()方法可以方便的变化观察者。
而Mediator模式的场景中，变化的是各个不同类型对象错综复杂的关系，把这个关系封装到Mediator中，改变关系只要维护Mediator就可以了。

我感觉学习设计模式的核心是掌握OO设计原则，《Head First设计模式》总结的OO设计原则作为贯穿全书的总线，这个很好
[该贴被kof99于2012-12-03 17:16修改过]

多谢各位的回复，最近我又有了一点新的心得和问题，各位看看能不能给点意见。
我觉得Listener的主要意图是“通知消息”，只要是我感兴趣的事件，我只管通知就好了，至于被通知的人干什么怎么干Listener不关心；UI事件就是这种典型情况。

Observer的主要意图是“联动”，正如update方法一样，被观察者发生改变观察者就能收到改变的东西用于改变自己；

他们的区别Listener是（有选择的）通知、Observer是（级联）更新；Listener和Observer从执行的角度看是一个东西，只是意图不同，用于解决的问题不同而已；

这么说可能觉得和废话一样，说个例子更清楚。
如：某斗地主游戏大厅，一个player在大厅内可以看到各个桌子的（状态）变化及大厅内player列表的（增减）变化。
从服务器广播角度来看，大厅的每一次状态变化，都要向大厅内所有client广播一个消息。作为并发服务器，一个数据可能在1秒内被更动N次。
这个时候如果采用以“通知”为意图Listener很明显不合适，因为收到通知和取数据是不同时间点，如果加同步锁还有可能引起死锁。
而以“更新”为意图的Observer看起来更靠谱一些，subject定义为房间内所有对象“数据的副本”，当事件源（player列表|桌子）发生改变就生成自己现在的数据快照，发送给subject保存并subject.notifyObservers(), 这样client就可以和服务器的subject同步更新了。

最后我想说的是Listener和Observer从代码看一个东西，如果用Listener干Observer的事，我觉得那个Listener就是Observer。

呵呵，各位老大见笑了，这是我这几天悟道的心得，希望多给点意见。
-----------------------------------------深夜的分割线-------------------------------------------------------------
顺便问一下，有关于DDD对于并发锁的使用在那能够看到相关资料？
我最近在使用Lock的时候总是感觉不得章法，到底是锁数据变更？还是锁业务方法呢？
[该贴被wd1603于2012-12-18 01:23修改过]