设计模式专题（十）——观察者模式
设计模式专题（十）——观察者模式
（原创内容，转载请注明来源，谢谢）
一、概述
观察者模式（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
相关阅读：