关于Mediator模式的疑惑--<<敏捷软件开发>>读书笔记系列

在<<敏捷软件开发>>一书中讲解Mediator模式举的是如下关系的一个例子:


用一个JList和一个JTextField构造了一个QuickEntryMediator类的实例.QuickEntryMediator向JTextField注册了一个匿名的DocumnetListener.(没有系统学过Java,这点上语法不是很清楚,但大致也知道在做什么). 每当文本发生变化时,这个listener就调用textFieldChanged方法.接着,该方法在JList中查找以这个文本为前缀的元素并选中它. (简单地说就是文本框内容发生变化后,list框要对这个变化响应.)
JList和JTextField的使用者并不知道该Mediator的存在.它安静地待着,把它地策略施加在那些对象上,而无需它们地允许或知晓.
然而看了Gof的和其它的设计模式的书(主要是<<Java与模式>>)发现Mediator模式的结构图如下:

感觉它们之间的差别挺大的.下面这张图明显要求Colleague对象需要知道Mediator而无需知道其余Colleagues(而且有一个抽象的Colleague类).当Colleague对象状态发生变化时它只需通知Mediator对象就行,Mediator对象自然会通知关心这一变化的Colleagues做出相应的变化.那么对于<<敏捷>>一书中的"JList和JTextField的使用者并不知道该Mediator的存在"该如何理解呢.
按照<<Java与模式>>一书将此模式比喻为团队管理,小组成员之间必须通过组长才能沟通,那么每个小组成员也必须知道哪个是组长,也就是Colleague对象必须拥有Mediator对象的引用.
然而<<敏捷>>一书例子的实现却非如此.两者之间的沟通是通过Mediator管理通过事件触发实现的, 难道这个是运用事件对此模式的一个简化? 
按照Gof 定义的Mediator意图:用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
那么<<敏捷>>一书给的例子是最简单不过,而且是非常符合这个意图的.Mediator负责JList和JTextField的交互,避免了两者之间的直接交互,从而解耦它们.

那么我们是否可以这么认为: 我才不管你怎么实现呢,我只要保证对象们之间不互相直接通讯,又能做到当自己(对象A)的状态改变时,能够触发到别的感兴趣的类做出响应,而对象A自己却完全不知道已经影响到了别人(这样就能保证"可以独立地改变它们之间的交互",我只要通过一个类如上面的QuickEntryMediator去管理沟通就好^_^), 那么就是Mediator模式,退一步说实现了Mediator的思想呢?

感觉这似乎跟Observer模式很像了,不知道它们之间真正的区别在哪里??, 个人感觉<<敏捷>>中举的例子的实现跟Observer模式用delegate简化实现是很相似的,只不过<<敏捷>>中少了一个抽象的Subject, 注册事件在QuickEntryMediator里面注册而已.思想上是及其接近的.

个人在设计模式这块还显得比较稚嫩,可能这些都是自己没有理解它们的精髓而产生错误的理解导致的疑惑罢了,期待大家能够指点迷津,拨乱反正.
能够找出别人表达的缺陷,我想也是一种沟通,指正别人错误也是对自己在这一方面思想的一次整理^_^