您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iProcess 课程 角色 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
交易系统中的观察者模式
 
作者:张松然 来源:linkedkeeper 发布于: 2017-7-25
1000 次浏览     评价:      
 

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

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

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

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

示例代码:

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(); //通知观察者
}
void finishOrder() {
...
}
//通知各个观察者
void addObserver() {
addObserver(ChargingObserver);
addObserver(DeductObserver);
addObserver(NoticeUserObserver);
...
}
}
//观察者基类
abstract class AbstractOrderFinishObserver implements Observer {
void update(Observable, args) {
param = parse(args);
try {
update(param);
} catch(...) {
...
}
}
abstract void update(param);
}
//扣点观察者
class DeductObserver extends AbstractOrderFinishObserver {
DeductSupport duductSupport;
void update(param) {
...
deductSupport.doDeduct ();
...
}
}
//计费观察者
class ChargingObserver extends AbstractOrderFinishObserver {
ChargingSupport chargingSupport;
void update(param) {
...
chargingSupport.charge();
...
}
}

在主题对象(OrderMessageResolver)中添加观察者列表(这里只列出了计费、扣点两个观察者,其他的类似,在此就不一一列举了),订单完成之后通知各个观察者。JDK自带对观察者模式的支持,笔者用的就是这个,原理和代码都很简单,大家可以自己去看源码。

这次重构有什么好处呢?首先,代码结构很清晰,在订单完成处理器(OrderMessageResolver)中,更新完订单状态就已经结束了,后续的逻辑都不是它的职责范围,只需要把订单完成的状态通知各个观察者,这样逻辑就不会耦合在一起。其次,重构后的代码具有良好的扩展性,后续再有订单完成之后的业务逻辑只需要添加一个观察者,不会对原来的代码有任何的入侵,这也符合OOP的设计原则—“对扩展开放,对修改关闭”。

最后,写一点自己的代码结构的看法,作为一个有腔调的工程师,我们要把我们写过的代码当做一件艺术品,不要放过上面任何的一点瑕疵,有“代码洁癖”完全不是一件坏事,在仔细雕琢的过程中,我们会有很多收获,也会让自己更好的成长。

 

   
1000 次浏览  评价: 差  订阅 捐助
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
 
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号