重构支付接口(一)支付接口存在的问题

一、现有支付接口存在什么问题

早期公司为了抢占市场快速迭代,遗留下来一屁股的技术债务,其中以支付宝、微信、平台币购买接口最为厉害,无数的价格计算、营销活动(助力、限时特价、拼团、优惠券等等)、商品类型判断代码交织在一个接口中,造成后期维护成本巨大,看不懂、不敢改。

业务逻辑层伪代码示意:
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 复用性强

公共代码抽取出来,各个支付接口复用这部分代码,例如创建订单、价格计算、营销活动处理等。

三、重构方案

打算采用简单工厂、策略对不同商品、不同活动的下单逻辑进行解耦,独立变化。将营销活动复杂的价格计算逻辑放到责任链中,支付接口代码只需要组装责任链调用就可得到最后的支付价格。

本篇先抛出目前支付接口遇到的问题,下一篇博文描写这种重构思路的设计和实现。

重构支付接口(二)重构方案

你可能感兴趣的:(重构支付接口(一)支付接口存在的问题)