`
coral0212
  • 浏览: 99872 次
  • 性别: Icon_minigender_1
  • 来自: 合肥
社区版块
存档分类
最新评论

观察者模式

 
阅读更多

 

观察者(Observer)模式的实例 

 

       观察者模式的其他的称呼又叫做发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。

 

       话说为什么也叫Dependents,为什么叫依赖?(从属者的翻译似乎太过于汉化,姑且叫着依赖吧)它是从这个角度思考的。定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。 

 

       模型-视图(Model/View),如果是C#从业人员,这个就不需要解释太多了,这里大致的说一下。MVVM模式,View:UI界面ViewModel:它是View的抽象,负责View与Model之间信息转换,将View的Command传送到Model;Model:数据层。简单的来说,就是model对象改变了相关的属性,就会立即通知到跟model关联的View对象,这样前端界面就发生了一连串的变化了。

 

有篇博文介绍观察者模式,引用了下面的例子,不考虑其实现方式。

 

哈票以购票为核心业务(此模式不限于该业务),但围绕购票会产生不同的其他逻辑,如:

 * 1、购票后记录文本日志

 * 2、购票后记录数据库日志

 * 3、购票后发送短信

 * 4、购票送抵扣卷、兑换卷、积分

 * 5、其他各类活动等

 

       类似的场景有,新员工入职,会有相关业务产生,如HR登记,财务工资登记,采购部领取工作服通知等等业务。再简单点的,各家快递公司送快递到前台,前台登记,通知相关人员领取。

 

       总结这一类的业务场景,都有一个共同点,就是先发生一个业务A,然后后续的B,C,D等业务都可以并行开展,在不考虑设计模式的情况下,一般的操作大致有两种,一种是同步执行,从B到D依次执行结束。还有一种就是消息队列异步执行,将各种实例需要执行的业务发送给队列,再执行,简单点的,新开3个线程,各自做各自的事情。

 

        如果这种是观察者模式(一个变种,作发布/订阅模式,观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。),那么是否合理呢?疑问如下:

 

       设计模式中的抽象主题subject对应的是订单,购票,员工入职等等行为,什么日志,通知,财务登记这些是一组观察者,当然也可以是一个。

 

       如果,把这些场景,放在代理模式下面,如何理解?

       快递这个活动,比如员工,我在上班,收快递,包括登记,完全指定前台来代理完成,让她给我代理把事情处理完。员工入职,可以找HR代理把所有剩下的手续事情都办理完毕,如果这样看来。代理模式是否也有一定的符合度呢?

 

       自己给自己的问题,做个大致的解答。他们之间的区别和联系到底在什么地方?

 

        代理模式的核心,在前面讲到了,就是代理者和被代理者都同时具备了抽象的功能,比如这里的前台能做的是收快递,HR登记等。但是收费快递,还得需要本人去付钱才能收货,不能完全交给前台代理了,前台代理只是一部分工作,并且登记入册,只能前台来做,是他自己职责,被代理者也不具备该功能。

 

      另外,代理模式还有一个最大的弊端,这个案例中体现在了,同步,前台可能只有一个,或许有多个,但是针对一个快递单子,他要一件一件的做。和代理模式区别较大。

 

       遇到这个案例,最佳的解决办法就是两种模式结合起来使用。快递公司有很多个,员工有更多了几百到上千个,此时如果不用代理模式,恐怕非常恐怖。但是观察者模式也必须得使用,如果有急件,登记,收费的快递,观察者模式,观察的对象就是拿到快递,接到快递这件事,拿到快递如果是收费,立即登记,并立即通知收件人过来取件或找人代付等等,但是接收快递本身是代理的对象,这个不矛盾,相互依存,不知道自己的描述是否清楚。

       观察者模式(C#版见http://www.cnblogs.com/promise-7/archive/2012/05/14/2500759.html)

       欢迎拍砖!

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics