<<向左走,向右走>>曾经骗去了我无数的眼泪.一首<<遇见>>更是改变了我人生的轨迹.虽然此篇只是技术文章,但借此也缅怀那段颓废的日子: 向左走,向右走
Observer核心思想在于订阅--发布.
比方说 有次外出公干,住在一宾馆内,事情很忙,没空外出观光,在房间里拼命赶Demo.突然发现有些测试资料不全,落在公司了,于是赶紧给同事打电话叫其快递过来.第二天事情仍然很多,但因为那份邮件的资料很重要,于是每隔一小段时间就去宾馆前台询问我的快递是否到了,这样严重打扰了我手头的事情,而且前台小妞也不高兴了, 她说这样吧你在我这里登记下你的房间号,等你快递到了我会帮你送过来的. 于是我就登记了一下, 回去忙着干自个的事了.也不知道过了多久,门铃响了,服务员客气的递给我一个包裹,快递终于来了,于是我放下手头的事情赶紧去测试那些未测的资料. (故事编的不好,见笑)
那么在这个故事里有几个要点: 1."我就登记了一下" 是一个订阅,登记的过程.2."门铃响了" 消息通知. 3."我放下手头的事情赶紧去测试那些未测的资料" 响应此事件 4.前台接到快递公司发给我的快递, 事件被触发.显然,前台如果收到的是别人的快递,是不会送给我的,意思就是说,我只关系我的邮件有没有到,我登记的主题只是"我的邮件到了",如果收到的是别人的邮件请不要来打扰我.
Observer模式详细可以参考下 吕震宇 : 设计模式（19）－Observer Pattern
Mediator核心思想是使本来一群关系错综复杂的群体,通过引入一个中间人,把原来成网状的关系梳理成星形结构
-------------->> 
曾经在读<<敏捷软件开发>>时候产生过关于Mediator和Observer的疑问:关于Mediator模式的疑惑--<<敏捷软件开发>>读书笔记系列
我们知道在C#里大家在提到Observer模式的时候,经常提到用Event可以简化实现Observer,事件也阐述的是一个订阅--发布的理念.这几天回过头来看我的那篇blog,有了些新的认识, 愚以为用Event的方式更像是Mediator模式.
Observer模式 和 Mediator模式都是用来传递消息的,但他们实现的手段是不一样的."显而易见"的是,Mediator模式中需要通过Mediator转发,所以Colleague要依赖于Mediator.然而在<<敏捷>>一书中Bob大叔明确指出Colleague并不一定要知道Mediator的存在.此事曾令我费解.
<<敏捷>>一书Mediator C#版
}
}Google了一些资料,想看看究竟Observer模式 和 Mediator模式本质的区别在哪里?
也重新看了一下<<Java于模式>>得到了一些启示,原话: 调停者模式与观察者模式是功能相类似的设计....观察者模式通过引入观察者对象和主题对象来达到将通信分散化的目的;而调停者模式则是封装了对象之间的通信,从而将通信集中在一个个中介对象中.
反复看了这段话得出的区别就是: 集中VS分散. Observer模式中观察者要跑去主题对象中注册,如果关注多个主题,均需要去各自的主题对象中注册.而Mediator模式Colleague各自间的关系是由Mediator组织的.从这个切入点去区别,我基本想通了为什么Bob大叔举的例子属于Mediator模式.
因为在这里QuickEntryMediator把Textbox,跟ListBox关联在一起,ListBox根本不知道TextBox的存在,信息都集中处理在QuickEntryMediator里.
按照我刚才的理解,确实吕震宇那篇文章中"C#中的Delegate与Event"一节中举的例子还有点Observer模式的味道,请注意看其是怎么实现的:
吕震宇的Observer delegate的实现然而实际上我们在使用Event的时候并不是这样,更多的情况是像Bob大叔举的例子那样使用.
在TerryLee .NET设计模式（19）：观察者模式（Observer Pattern）
此种方式是我们一般使用Event的方式,其天平已经偏向于Mediator模式了,只不过在这里由client负责组装他们的关系,(充当Mediator?可以这么理解吧)就如我上面阐述的一样,不知你是怎么认为的呢?
向信息集中走,向信息分散走
(PS:此文仅在于模式探讨,实际上用Event通知消息属于何种模式并不重要,纯粹理论上的较真,欢迎拍砖!)