利用设计模式优雅地消除业务代码中大量的if/else和重复逻辑

前言

if…else…绝对是我们日常编码中用到最多的，但是过多的使用，会导致我们代码可读性极差，并且一点也不美观。

但是在一些场景下，我们可以使用设计模式来进行优化，让你的业务代码不仅优雅简洁，而且可扩展性极强。

业务场景

我们先来说一个业务场景：

假如你在对接三方支付，这时候可能有支付宝、微信、银联三个产品需要对接，你需要根据用户选择交易类型来使用具体的三方平台。

解决方案1

大多数人的想法可能会很直接：

UserPayService.class

public class UserPayService {

    public void userPay(){
        if("微信".equals(type)){
            // 执行微信相关逻辑
        }else if("支付宝".equals(type)){
            // 执行支付宝相关逻辑
        }else if("银联".equals(type)){
            // 执行银联相关逻辑
        }else {
            // 执行未匹配逻辑
        }
        
    }

一套if…else…下来，功能是实现了，你的代码也变得极其臃肿，这种方案肯定是不可行的。

解决方案2

既然具体业务逻辑放在一个实现类会显得臃肿，那我把这些实现类拆分开来不就好了吗？

于是一些聪明的人可能会对方案1做如下改造：

AliPayService.class

@Service
public class AliPayService {

    public void pay(){
        // 执行支付宝相关逻辑
    }

}

UserPayService.class

@Service
public class UserPayService {

    @AutoWrite
    AliPayService aliPayService;
    @AutoWrite
    WechatPayService wechatPayService;
    
    public void userPay(){
        if("微信".equals(type)){
            // 执行微信相关逻辑
            wechatPayService.pay();
        }else if("支付宝".equals(type)){
            // 执行支付宝相关逻辑
            aliPayService.aliPay();
        }else if("银联".equals(type)){
            // 执行银联相关逻辑
            unionPayService.pay();
        }else {
            // 执行未匹配逻辑
        }
    }
}

通过将代码具体实现逻辑进行实现类拆分，我们的UserPayService不再那么臃肿了，但是问题依旧存在：if…else…依旧充斥着我们的代码，看起来还是不够优雅。

而且我现在只有三种支付类型，如果以后有五种，十种呢？总不能一直这样吧？

利用工厂模式消除if…else…

有读者可能已经注意到了，既然我能够提前知道用户选择的是微信还是支付宝，那是不是我可以把具体支付类型的实现类抽离出公共接口，通过这个type来动态选择实现类呢？

通过这个ThridPayService，我们只需要在业务代码根据type选择具体的实现类就可以了：

@Service
public class UserPayService {

    @AutoWrite
    Map<String,ThridPayService> thridPayServiceMaps;
    
    public void userPay(){
        thridPayServiceMaps.get(type).pay();
    }
}

这种套路的使用前提是，你必须能够动态判断类型，然后根据自动注入的实现类beanName去选择具体的实现类。

当然，还有更增强版的实现方式就是结合枚举类。这里交给读者去实现。

至此if…else…是消除了，但是假如需求一变，产品经理给你说，使用支付宝支付的用户可以享受95折优惠，使用银联支付的用户支付完成后要加积分，这时候又该怎么办？

如果在这种情形下，你又第一时间想到if…else…，那你就该反思自己设计模式有没有学习过了。

利用模板方法模式消除公共逻辑

既然我们已经把支付逻辑抽象成接口了，那么刚才的新需求来仔细思考一下：
支付享受优惠，这是支付前需要做的，支付完之后加积分，这是支付后需要做的，也就是说，我们的真正流程应该是这样的：

1. 处理支付前的逻辑
2. 调用三方支付实现类进行支付
3. 处理支付后的逻辑

那么我们对上述类图再做如下改动：

AbstractThirdPayService.class：

public abstract AbstractThirdPayService implement ThirdPayService{


    public void process(){
        before();
        pay();
        after();
    }

    public void before(){
        // 进行参数校验
        check();
    }
    
    @override
    public void pay(){
        // 默认什么也不做，交给具体的实现类
    }

    public void after(){
        // 进行支付完成后的逻辑
    }
}

没错，在这里我们使用了抽象类AbstractThirdPayService，它的作用就是为具体实现类提供默认的实现逻辑。

比如说支付前需要检验某些参数，我们可以把这个逻辑放在AbstractThirdPayService的before方法中，如果某个具体实现类需要改动逻辑，只要把before方法重写即可。

更妙的是，我们对业务类只需要做一点点改动，就可以完美支持：

@Service
public class UserPayService {

    @AutoWrite
    Map<String,AbstractThirdPayService> thridPayServiceMaps;
    
    public void userPay(){
        thridPayServiceMaps.get(type).process();
    }
}

这样一来，就算后面产品经理给你加再多的三方支付，加再多的积分、抽奖、优惠券、满减等千奇百怪的条件，你都可以游刃有余。