业务复杂=if else？刚来的大神竟然用策略+工厂彻底干掉了他们！

对于业务开发来说，业务逻辑的复杂是必然的，随着业务发展，需求只会越来越复杂，为了考虑到各种各样的情况，代码中不可避免的会出现很多if-else。

一旦代码中if-else过多，就会大大的影响其可读性和可维护性。

首先可读性，不言而喻，过多的if-else代码和嵌套，会使阅读代码的人很难理解到底是什么意思。尤其是那些没有注释的代码。

其次是可维护性，因为if-else特别多，想要新加一个分支的时候，就会很难添加，极其容易影响到其他的分支。

笔者曾经看到过一个支付的核心应用，这个应用支持了很多业务的线上支付功能，但是每个业务都有很多定制的需求，所以很多核心的代码中都有一大坨if-else。

每个新业务需要定制的时候，都把自己的if放到整个方法的最前面，以保证自己的逻辑可以正常执行。这种做法，后果可想而知。

其实，if-else是有办法可以消除掉的，其中比较典型的并且使用广泛的就是借助策略模式和工厂模式，准确的说是利用这两个设计模式的思想，彻底消灭代码中的if-else。

本文，就结合这两种设计模式，介绍如何消除if-else，并且，还会介绍如何和Spring框架结合，这样读者看完本文之后就可以立即应用到自己的项目中。

本文涉及到一些代码，但是作者尽量用通俗的例子和伪代码等形式使内容不那么枯燥。

恶心的if-else

假设我们要做一个外卖平台，有这样的需求：

1、外卖平台上的某家店铺为了促销，设置了多种会员优惠，其中包含超级会员折扣8折、普通会员折扣9折和普通用户没有折扣三种。

2、希望用户在付款的时候，根据用户的会员等级，就可以知道用户符合哪种折扣策略，进而进行打折，计算出应付金额。

3、随着业务发展，新的需求要求专属会员要在店铺下单金额大于30元的时候才可以享受优惠。

4、接着，又有一个变态的需求，如果用户的超级会员已经到期了，并且到期时间在一周内，那么就对用户的单笔订单按照超级会员进行折扣，并在收银台进行强提醒，引导用户再次开通会员，而且折扣只进行一次。

那么，我们可以看到以下伪代码：

public BigDecimal calPrice(BigDecimal orderPrice, String buyerType) {

    if (用户是专属会员) {
        if (订单金额大于30元) {
            returen 7折价格;
        }
    }

    if (用户是超级会员) {
        return 8折价格;
    }

    if (用户是普通会员) {
        if(该用户超级会员刚过期并且尚未使用过临时折扣){
            临时折扣使用次数更新();
            returen 8折价格;
        }
        return 9折价格;
    }
    return 原价;
}

以上，就是对于这个需求的一段价格计算逻辑，使用伪代码都这么复杂，如果是真的写代码，那复杂度可想而知。

这样的代码中，有很多if-else，并且还有很多的if-else的嵌套，无论是可读性还是可维护性都非常低。

那么，如何改善呢？