一次代码优化的经历：设计模式的使用

背景：最近参与的一项版本线的开发工作时，需要大幅度修改原先系统的老代码（也就是俗称的屎山），在分析需求的过程中，发现原先的代码存在许多的不合理之处，这些需求是跟批量支付打款业务相关的，因为有许多不同的第三方支付通道的接入，因此在原先的代码中针对每一个通道都写了一套异步执行的代码，而这些代码全部存在与系统A中，而这次新的需求中，要求我们可以在系统A中增加一种托管模式，如果用户开通了托管模式，则将支付的具体操作交由系统B来操作，而这两个系统又是需要互不影响，相互独立的，那么问题来了，如何在系统B中增加支付操作呢？

思考：首先我分析了这两个系统的代码结构，发现他们均依赖于一个名为C的服务，而原先的A系统中调用支付的逻辑是将大量操作写在了本系统中，只是具体调用第三方的接口的代码放在了C的服务中，考虑到这一点，我决定改造原先的支付代码，将其从A系统转移到C,对外只提供简单API。

问题：原先的代码结构如下图所示：

调用打款的判断逻辑

异步线程调用具体的操作

问题一：上述代码存在与controller层，有没有觉得很容易冗余，并且不够简洁，日后维护也不好维护

具体的操作

问题二：如上述所示，这些判断逻辑在每一个通道的代码里几乎都有，举个例子，天津畅捷和合肥畅捷的支付代码几乎完全一样，只是调用第三方的接口不一样，以及部分判断不一样，但代码几乎完全复制了一遍，这也是我今天要分享的主要内容，要改造这些冗余的代码。

解决方案：下面就开始动手改造，首先第一步转移代码到C服务中，

第一版修改，统一的调用接口

但只是将这些方法全部复制到此公共接口中，并不能解决代码冗余的问题，只是优化了以后的维护操作

第二版修改，直接做成工厂方法，实例不同对象并调用

这些对象的设计图如下图所示

支付通道类设计

顶层支付通道抽象类

AbstractPayChannel

    支付通道辅助接口

PayChannelMaker

民生通道的打款代码

CMBCPayChannel

合肥民生的支付通道代码：

HeifeiCMBCPayChannel

天津民生支付通道的打款代码：

TianjinCMBCPayChannel

相信看到这里，大家已经知道了这样设计的优点了，首先是对于同一个通道类型而言，保持了其公共代码的不变性，当需要接入不同地方的同一通道支付的时候，几乎不需要写过多的代码，类似配置的操作就可以解决这个问题。其次通过抽象类的方式保存公共代码，可以做到一次修改，处处生效的效果，避免了小改动引发的一些不必要问题，这次设计采用了设计模式中的模板方法模式，其核心在于给出一个算法的逻辑实现骨架，将对应的实现延迟到具体的子类中。有兴趣的的话，推荐大家去看一下《大话设计模式》这本书，书中介绍的很详细，在此我就不再赘述了。