一、现有支付接口存在什么问题
早期公司为了抢占市场快速迭代，遗留下来一屁股的技术债务，其中以支付宝、微信、平台币购买接口最为厉害，无数的价格计算、营销活动（助力、限时特价、拼团、优惠券等等）、商品类型判断代码交织在一个接口中，造成后期维护成本巨大，看不懂、不敢改。
业务逻辑层伪代码示意：
1.平台币下单：
public void coinPay() {
100行支付校验代码和一大堆if else
200行营销活动判断代码
商品类型判断，以及价格计算，500行代码
创建订单完成订单50行代码
扣除平台币
增加流水记录
}
2.支付宝下单
public void aliPay() {
100行支付校验代码和一大堆if else
200行营销活动判断代码
商品类型判断，以及价格计算，500行代码
创建订单40行代码
调用第三方支付sdk，得到预付单信息返回
}
3.微信下单：
同支付宝下单，几乎除了调用支付sdk代码外都是复制粘贴。
支付完成回调接口也和下单接口一样，以上代码掺杂了五六种商品类型判断和五六种活动类型判断，活动存在互斥和共存关系，如此复杂的逻辑全用if else堆砌，后期要上手维护时，代码的画风是这样的：
// 正常购买
boolean notPinActivity = "null".equals(pinTaskId);
if (notPinActivity)
{
if (goodsInfo.getType() == CommonConstants.PRODUCT_TOPIC) // 如果是专题，则添加子课程的购买关系
{
saveTopicSubjects(productId, userId);
}
if (goodsInfo.getType() == CommonConstants.PRODUCT_SUBJECT
|| goodsInfo.getType() == CommonConstants.PRODUCT_TOPIC) // 非问诊订单才添加购买关系
{
UserBuySubject userBuySubject = new UserBuySubject();
userBuySubject.setId(CommonUtil.getUuid());
userBuySubject.setUserId(userId);
userBuySubject.setSubjectId(productId);
userBuySubject.setCreateTime(new Date());
userBuySubject.save();
}
else if (goodsInfo.getType() == CommonConstants.PRODUCT_DIAGNOSIS)
{
Diagnosis diagnosis = Diagnosis.dao.findById(productId);
order.setServiceEndTime(
DateUtil.addSecond(new Date(), diagnosis.getDuration()));
}
else if (goodsInfo.getType() == CommonConstants.PRODUCT_VIP)
{
order = vipService.buyVip(order, userId, productId);
//如果购买VIP时存在分销人，则加入分销逻辑,ibos定时退款6-12小时内
if(StrKit.notBlank(fromUserId) && !fromUserId.equals("null"))
{
ActivitySellRecord sellRecord = new ActivitySellRecord();
ActivitySell sell = goodsInfoService.findActivitySell(productId);
//获取设置的返利金额
//TODO 这里是用实际支付的金额的50% 返利， 如果用后台设置的金额，需要考虑学农币购买的情况
/*int sellCommision = vipService.getSellCommision(productId, sell.getFee());*/
if(null != sell && CommonConstants.DEFAULT_STATUS_ENABLE == sell.getStatus())
{
sellRecord.setSellId(sell.getId());
sellRecord.setSellUser(fromUserId);
sellRecord.setBuyUser(userId);
sellRecord.setOrderId(order.getId());
sellRecord.setStatus(CommonConstants.FALSE);
// 以前的线下分销计算规则
// int amount = Integer.parseInt(cash_fee) / 2;//固定50%
// sellRecord.setFee(amount < 100 ? 100 : amount);
int amount = Integer.parseInt(cash_fee);
sellRecord.setFee(activityService.
calcSellFee(amount, sell.getFeeType(), sell.getFee(), order.getPayType()));
sellRecord.save();
}
}
}
}
// 拼团活动购买
else
{
log.info("拼团支付成功！进入拼团处理逻辑！userId:" + userId + ",pin_task_id:" + pinTaskId
+ ",subject_id:" + productId);
int pinProductType = activityService.getPinProductTypeByGoodsType(goodsInfo.getType());
pinTaskId = activityService.pin(userId, pinTaskId, productId,
order.getOrderNo(), source, appletFormId, pinProductType);
order.setDesc(pinTaskId);
}
以上画风代码延绵五百行。
以上代码存在的几个问题##：
1.可读性差
主干逻辑不清晰，不看上个把小时不知道这几百行代码做了什么。
2.可扩展性差
新增一种商品或者活动，要全面修改代码，不符合开闭原则。
3.代码冗余度高
同样的代码在每一种支付方式的接口都写了一遍，修改的时候要修改三处。
二、我想要一个什么样的支付接口
2.1 可读性好
主干逻辑清晰，一目了然这个接口核心逻辑走了哪几步，每一步分别做了什么。
2.2 可扩展性好
后期加入一个商品或者加入一个活动，只需要新增代码，不需要修改历史代码。
2.3 复用性强
公共代码抽取出来，各个支付接口复用这部分代码，例如创建订单、价格计算、营销活动处理等。
三、重构方案
打算采用简单工厂、策略对不同商品、不同活动的下单逻辑进行解耦，独立变化。将营销活动复杂的价格计算逻辑放到责任链中，支付接口代码只需要组装责任链调用就可得到最后的支付价格。
本篇先抛出目前支付接口遇到的问题，下一篇博文描写这种重构思路的设计和实现。
重构支付接口（二）重构方案