设计模式专题（十）——观察者模式

设计模式专题（十）——观察者模式

（原创内容，转载请注明来源，谢谢）

一、概述

观察者模式（Observer），又称做发布-订阅模式（Publish/Subscribe），定义了一种一对多的依赖关系，让多个观察者对象监听同一个主题对象。当主题对象状态变化时，会通知所有观察者对象，让他们能够自动更新自己。

该模式下，将发布者和消费者都设定一个抽象，发布者发布消息，消费者收到消息后会自动进行后续的操作，不同的消费者收到同一个消息，可以有不同的操作。

但是，这样会使得发布者和订阅者之间的耦合度过高，且会使得消费者之间被绑定在一起。通常情况下，消费者是一些毫不相关的类，如用户完成支付后，同时给用户发送短信提醒、微信推送、站内信，且还需要给发货系统发送一个新的订单，给仓库发送一个提货信息，本系统内部也需要记录操作日志、数据入库等。这些操作完全不一样，无法使用一个统一的方式来实现。

在C#中可以用委托配合发布订阅的方式作为解决方案，在PHP中可以自行实现委托。

二、类图

此类图为普通的观察者模式类图，在上文中说的改进版的类图，解除消费者之间的关系，因此撤掉上图的Observer类，使每个消费者各自独立。

三、业务场景

1、场景分析

现实现上述用户支付完成后的场景，考虑到多个用户在短时间内都完成支付，因此还需要加上消息队列。

1）抽象类Subject，定义发布者需要执行的方法。

2）发布类ConcreteSubject，具体实现发布。

3）Observer1、Observer2… 若干消费者，实现各自的功能。

2、伪代码实现

1）抽象发布类

抽象发布类主要是将动态添加发布方法这一操作提取出来，其他的具体发布类都可以直接使用此方法。

         abstractclass Subject{
         protected $events;
         public function__construct(){
                   $this->events= array();
         }
         //定义不同的发布方式
         public functionsend(){}
         //添加类型：类的实例-》方法名-》参数
         public functionaddEvents($obj, $func, $args){
                   array_push($events,array($obj, $func, $args));
         }
}

2）具体发布类

具体发布类将发布的信息，以类作为key，存在消息队列中（如redis）。

class ConcreteSubject extends Subject{
         public functionsend(){
                            foreach($this->events as$event){
                            //redis->lpush(get_class($event[0]),array($event[1], $event[2]))
                   }
         }
}

3）具体消费者

具体消费者通过redis去不断的取各自的服务，在收到请求后立即执行各自的服务。

四、评价

观察者模式，通过结合消息队列，使得发布者和消费者之间完全隔离开。

对某个事件的触发，由发布者进行执行，并且由发布者判断要发送给哪些消费者。

对事件的处理，由消费者在自己的消息队列中取内容进行处理，当队列为空时处于等待状态（或者几分钟处理一次，可以根据具体情况设置处理策略），当队列收到来自发布者发布的内容后。

例如用户支付后，短信模块（消费者）收到支付模块（发布者）的发送短信告知用户支付成功的消息，短信模块再去做自身的处理。

这样使得类之间耦合度降低，且当发生故障时，也很容易排查故障发生的模块。例如短信没有发送成功，支付模块查看是否有发送消息给短信模块，并且查看发送的内容是否符合规范；短信模块判断是否因为修改逻辑，或其他bug，导致短信无法发送。

——written by linhxx 2017.08.02

相关阅读：

设计模式专题（九） ——外观模式

设计模式专题（八） ——模板方法模式

设计模式专题（七）——建造者模式

设计模式专题（六）——原型模式

设计模式专题（五）——工厂方法模式

设计模式专题（四）——代理模式

设计模式专题（三）——装饰模式

设计模式专题（二）——策略模式

设计模式专题（一）——面向对象的设计原则