前言

有没有同学遇到过一个方法中几十个的if/else或者switch判断，然后根据判断处理业务逻辑。一个方法几百上千，甚至几千行代码？有没有同学入职刚接手项目发现代码注释写着：“同学，听我的，别动这个代码，你改不动。因为做为作者的我，自己也改不动？”，然后，就只能望码（yang）兴叹？

注：为简化代码数量，未做完善的条件判断！开发时请编写完善的判断。

if-else分支判断逻辑

以商品折扣活动来说，不同的商品折扣活动会有不同的价格计算方式。

public int getPrice(Order order) {
    OrderType orderType = order.getOrderType();
    int price = order.getPrice();
    if (orderType == OrderType.NORMAL) {
        // 普通订单折扣
    } else if (orderType == OrderType.GROUPON) {
        // 拼团订单折扣
    } else if (orderType == OrderType.PROMOTION) {
        // 促销订单折扣
    }
    return price;
}

在这个例子中，就是使用分支判断法进行订单类型的判断，然后根据不同的订单类型处理不同的业务逻辑。

如果说，订单的折扣业务基本上不变，或者处理逻辑很简单，并不会影响阅读，那么，简单的分支逻辑是不会有问题的。

但是在软件世界中，变化永远来得很突然。今天产品经理跟你说：“确定了，就这么干！”。明天，产品经理跟你说：“这个需求有点变化，但是变化不大！”。而产品经理的这个不大的定义永远是：“世间除了生死，其他都是擦伤”。

在上面的if-else分支判断代码中，需要新加这样的一个需求：“现在需要新加一个秒杀活动”。

那么，只能修改当前的代码，添加额外的分支逻辑else if (orderType == OrderType.SECKILL) { // 秒杀订单折扣 }。

明天产品经理说：“现在要求拼团订单以及促销订单折扣的时候，可以自动折扣积分进行折上折”，那么只能在发前的代码中添加新修改的逻辑。暂止不说将所有的业务判断逻辑柔和在一个方法中导致的代码复杂度，单单这种需要变化变更代码带来的测试工作量已经是非常巨大了。

因为变化了一个方法，而这个方法内部有多个业务逻辑，那么，该方法涉及到的业务逻辑都需要经过测试人员的回归测试才可以被准许上线，而这个过程，在公司里面，往往是比较复杂的。

那么，我们如何来修改上面的代码，降低影响面呢？

策略模式

人都是惰性的！有多少人想过衣来张手，饭来张口的生活呢？冷了有专门的人给你穿衣，饿了有专门的人给你做饭。

是不是感觉这样的生活挺好的。不，其实这样的生活还是挻麻烦的，我饿了得叫：“做饭保姆，我饿了”，冷了得叫“穿衣保姆，我冷了”，还需要忘记什么事情对应谁来处理，多累呀。所以，这个时候得有个管家！！

所以，对应到服务中，我们当然也是希望当不同的订单折扣需要处理时，如果有这个一个容器放置了对应的折扣处理逻辑，我们只需要从容器中拿到对应的处理器执行就可以，而并不需要关注处理器内部处理了什么内容，这样是不是非常的舒服呢？首先，我们先定义一个折扣处理器，用来处理不同的折扣，也就是对应饿了做饭，冷了穿衣的逻辑。

在这个类图中，其中，业务服务就是“懒惰的我”，DiscountProcessorFactory就是管家，管家管理所有的折扣处理器。

//创建一个折扣处理工厂
public class DiscountProcessorFactory {
    private static final Map<OrderType, DiscountProcessor> DISCOUNT_PROCESSORS = new HashMap<>();
    static {
        //将折扣处理器添加到处理工厂中
        DISCOUNT_PROCESSORS.put(OrderType.NORMAL,new NormalDiscountProcessor());
        DISCOUNT_PROCESSORS.put(OrderType.GROUPON,new GrouponDiscountProcessor());
        DISCOUNT_PROCESSORS.put(OrderType.PROMOTION,new PromotionDiscountProcessor());
        DISCOUNT_PROCESSORS.put(OrderType.SECKILL,new SeckillDiscountProcessor());
    }
    public static DiscountProcessor getDiscounter(OrderType orderType){
        return DISCOUNT_PROCESSORS.get(orderType);
    }
}

//执行折扣
public int getPrice2(Order order) {
    OrderType orderType = order.getOrderType();
    return OrderDiscountFactory.getDiscounter(orderType).process(order);
}

这样，对于原来挤压在一起的大量的业务代码，是不是变得非常的清晰呢？而且，这种设计可以起到分离的作用，需要修改业务逻辑时，也仅是影响到对应的折扣类型，不会影响到其他的折扣类型。

这就是策略模式：定义一族算法类，将每个算法封装起来，让它们可以互相替换。策略模式可以使算法的变化独立于使用它们的客户端。

通用类图如下：

在SpringBoot中应用

在上面的代码中，如果新添加一种策略，需要二个步骤：

• 添加新的策略算法
• 将新的策略算法添加到算法工厂中

那么，是否还可以简化？只需要添加新的策略，服务可以自己识别到呢？我们可以结合Spring的Bean容器来自动发现新的算法，自动添加到容器中。

定义一个算法标识注解

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Component
public @interface Discounter {
    OrderType value();
}

将折扣算法处理器添加该注解

@Discounter(OrderType.NORMAL)
public class NormalDiscountProcessor implements DiscountProcessor {

    @Override
    public int process(Order order) {
        return 0;
    }
}

到这一步，Spring已经可以将对应的DiscountProcessor注册到Bean容器中了，现在我们还需要一个管家，管家用来判断在什么情况使用谁来处理。

算法管家类

public class AssembleDiscountProcessor implements DiscountProcessor {

    private final Map<OrderType, DiscountProcessor> processors = new HashMap<>();

    public AssembleDiscountProcessor(List<DiscountProcessor> discountProcessors) {
        for (DiscountProcessor discountProcessor : discountProcessors) {
            Discounter discounter = discountProcessor.getClass().getAnnotation(Discounter.class);
            this.processors.put(discounter.value(), discountProcessor);
        }
    }

    @Override
    public int process(Order order) {
        OrderType orderType = order.getOrderType();
        return this.processors.get(orderType).process(order);
    }
}

定义自动装配器

以idea为例，在项目的resource下新建：META-INF/spring.factories

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
  org.orghost.pattern.design.strategy.DiscountProcessorAutoConfiguration

@Configuration(proxyBeanMethods = false)
public class DiscountProcessorAutoConfiguration {

    @Bean
    public DiscountProcessor discountProcessor(List<DiscountProcessor> discountProcessors) {
        return new AssembleDiscountProcessor(discountProcessors);
    }
}

使用

完成上面的部署之后，所有的算法处理器会自动被Spring容器管理，我们使用上只需要：

@Service
public class OrderService {

  @Autowired private DiscountProcessor discountProcessor;

  public int getPrice(Order order) {
    return this.discountProcessor.process(order);
  }
}

到此，如果要新增一个折扣算法，只需要新增一个DiscountProcessor实现类，并注解@Discounter(OrderType.NORMAL)即可以完成自动匹配。

小结

经常，我们一提到if-else分支判断，就觉得它是烂代码。如果if-else分支判断并不复杂，代码不多，这其实是没有问题的。存在即合法，如果if-else一定要去除，那么语法上不会就提供这种用法了。我们在编写代码的时候，应该尽量的保持代码的简单，即应该符合KISS原则。如果仅仅是为了去除if-else，我觉得这是一种过度的设计，反而不美。

最后，策略模式经常被用来解决if-else的分支判断问题，但是我们需要记住，策略模式本质上的主要作用是解耦策略的定义、创建与使用，让每个部分的代码不至于过于复杂、代码量过多，最小化、集中化代码管理，降低修改时的影响范围。其次，策略模式在新增策略时并不需要改动其他的代码，更加符合开闭原则。

最后的最后，同学们可以找找看代码中是否有大量的if-else的代码，尝试用策略模式来美化一下你的感观吧。