最近在重构中用到了设计模式中的观察者模式，简单的跟大家分享一下观察者模式的原理和使用场景。
在进入正题之前，先简单的介绍一下业务场景，交易系统中很重要的一个流程就是订单状态的流转，这次重构的就是订单完成的部分。
订单完成之后，要做很多的后续工作，比如通知用户、发起计费、扣点、通知相关系统等。
重构之前的代码结构如下：
示例代码：
这种结构有几大缺点：
第一，resolve方法里面做了太多的逻辑，导致代码的可读性极差，维护起来也相当麻烦。
第二，有很多逻辑并不是OrderMessageResolver这个类应该负责的，已经超过了这个类的职责，这与面向对象的设计理念是相违背的。
第三，很难扩展，随着业务的发展，订单完成之后肯定还会有更过的动作，后面在添加业务逻辑的时候会非常困难，对这个方法的修改也是相当危险的，你很难知道你新加的逻辑会不会对之前的逻辑产生影响，对于的交易系统来说，一旦产生一些数据上的误差，损失是非常惨重的。
针对以上这些问题，引入观察者模式解决，观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时，会通知所有的观察者对象，使他们能够自动更新自己，主题与观察者之间是一种发布-订阅的关系。
下面是JDK对观察者模式支持的类图：
在本例中，订单的完成状态就是被观察的主题，而完成后的各个动作就是不同的观察者。
重构之后：
示例代码：
在主题对象（OrderMessageResolver）中添加观察者列表（这里只列出了计费、扣点两个观察者，其他的类似，在此就不一一列举了），订单完成之后通知各个观察者。JDK自带对观察者模式的支持，笔者用的就是这个，原理和代码都很简单，大家可以自己去看源码。
这次重构有什么好处呢？首先，代码结构很清晰，在订单完成处理器（OrderMessageResolver）中，更新完订单状态就已经结束了，后续的逻辑都不是它的职责范围，只需要把订单完成的状态通知各个观察者，这样逻辑就不会耦合在一起。其次，重构后的代码具有良好的扩展性，后续再有订单完成之后的业务逻辑只需要添加一个观察者，不会对原来的代码有任何的入侵，这也符合OOP的设计原则—“对扩展开放，对修改关闭”。
最后，写一点自己的代码结构的看法，作为一个有腔调的工程师，我们要把我们写过的代码当做一件艺术品，不要放过上面任何的一点瑕疵，有“代码洁癖”完全不是一件坏事，在仔细雕琢的过程中，我们会有很多收获，也会让自己更好的成长。
作者：张强，16年加入京东，目前就职于京东商城京麦平台组，从事京东对外开放平台和服务于第三方入驻商家的相关工作，开源爱好者，对常用开源框架如Spring、Mybatis、Dubbo等有源码级别的了解，热衷于研究各种技术，致力于成为一名有腔调的工程师
更多精彩文章，请访问 LinkedKeeper 社区 www.linkedkeeper.com
欢迎关注“LinkedKeeper”微信公众号。LinkedKeeper 是一个致力于打造高品质的技术资源社区。
欢迎关注“LinkedKeeper”微信公众号。
网友评论