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