策略模式的多种实现

最近几天好好补了下血，才恢复了点精力。所以有了一点写些啥的欲望，那就写一下设计模式好了。

设计模式，相信大家应该都或多或少的接触过。总的来说，设计模式是一些前辈们在开发过程中面对一些常见问题抽象出来的通用解决方案，而且也经过了相当长时间的验证，普适性极强，对于大多数问题基本上都能解决。当然如果自己的业务确实比较特别，那现有的设计模式可能也确实无法满足。而且咱们这个行业也是在发展的，现在适用的设计模式可能过一段时间就不怎么适用了，也可能有些大佬发现了更好的设计抽象出来之后成了另一种设计模式。当然，现在的真实情况大多数是对多个设计模式的组合以及变种等。

注意：设计模式不能滥用哦，不合理的使用设计模式反而会使代码变得更加复杂，所以不要炫技。

介绍了这么多，那么什么是策略模式呢？顾名思义，就是当同一个行为可以有不同的策略的时候，通过某种条件(策略)选择某一个具体的策略实现执行方法。比如支付，支付本身是一个行为，但是可以选择微信支付、支付宝支付、银联支付和聚合支付等多种策略，这种就可以使用策略模式。可以减少很多if else语句块。

策略模式的优缺点：

优点：

1. 避免多重的条件判断
2. 易扩展

缺点：

1. 代码量增多
2. 策略实现需要对外暴露

可以先看看如果没有使用策略模式，那我们在遇到扩展时是怎么处理的。就拿支付来举例吧。伪代码如下：

public String doPay(PayParam payParam) {
    // 先验
    preCheck(payParam);
    String result = null;
    if(payParam.getPayChannelEnum() == PayChannelEnum.ALI) {
        // 支付宝支付的一些校验和处理
        result = doAli(payParam);
    } else if (payParam.getPayChannelEnum() == PayChannelEnum.WECHAT) {
        // 微信支付的一些校验和处理
        result = doWechat(payParam);
    } else {
        // 其他情况的处理
        result = null;
    }
    // 结果处理
    result = resultHandle(result);
    return result;
}

这个时候如果又加上了银联支付，那么就得在这个if else的分支上进行修改，再加一个分支，如果我们的处理不只是这么简单的话，甚至还涉及到代码结构的调整，先验和结果处理调整，这不符合代码封装的开闭原则。而且也会改得很令人头痛。

策略实现