观察者模式

 

观察者(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)

       欢迎拍砖！