交易系统中的观察者模式
您目前处于:编程  2017年07月12日

最近在重构中用到了设计模式中的观察者模式,简单的跟大家分享一下观察者模式的原理和使用场景。

在进入正题之前,先简单的介绍一下业务场景,交易系统中很重要的一个流程就是订单状态的流转,这次重构的就是订单完成的部分。

订单完成之后,要做很多的后续工作,比如通知用户、发起计费、扣点、通知相关系统等。

重构之前的代码结构如下:

示例代码:

class OrderMessageResolver implements MessageResolver {
	DeductSupport duductSupport;
	ChargingSupport chargingSupport;
	MQSender mqSender;
	void resolve(){
    	...
		finishOrder(); //完成订单
        charge() //计费;
		deduct() //扣点;
		mqSender.send(); //发消息
		...

	}
	void finishOrder() {
		...
	}
	void charge() {
    	...
    	chargingSupport.charge();
    	...
	}
	void deduct() {
    	...
    	deductSupport.doDeduct ();
    	...
	}
	void noticeUser() {
		...
		mqSender.send();
		...
	}
}

这种结构有几大缺点:

第一,resolve方法里面做了太多的逻辑,导致代码的可读性极差,维护起来也相当麻烦。

第二,有很多逻辑并不是OrderMessageResolver这个类应该负责的,已经超过了这个类的职责,这与面向对象的设计理念是相违背的。

第三,很难扩展,随着业务的发展,订单完成之后肯定还会有更过的动作,后面在添加业务逻辑的时候会非常困难,对这个方法的修改也是相当危险的,你很难知道你新加的逻辑会不会对之前的逻辑产生影响,对于的交易系统来说,一旦产生一些数据上的误差,损失是非常惨重的。

针对以上这些问题,引入观察者模式解决,观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时,会通知所有的观察者对象,使他们能够自动更新自己,主题与观察者之间是一种发布-订阅的关系。

下面是JDK对观察者模式支持的类图:

在本例中,订单的完成状态就是被观察的主题,而完成后的各个动作就是不同的观察者。

重构之后:

示例代码:

class OrderMessageResolver extends Observable implements MessageResolver {
	void init() {
		addObserver(); //初始化添加观察者
	}
	void resolve() {
		finishOrder(); //完成订单
		notifyOvservers(