设计模式之策略模式

        “定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。”

---

1 简介

        假如说现在需要实现个方法，获取订单商品的价格。因为订单类型的不同，计算价格的方式也会有所不同。常规的写法如下所示：

public BigDecimal getOrderPrice(String subOrderSn, Long skuId) {
    //获取子单
    OrderSubDO orderSubDO = orderSubMapper.findBySubOrderSn(subOrderSn);
    //获取子单商品
    List<OrderDetailDO> orderDetailDOS = orderDetailMapper.selectBySubOrderSn(subOrderSn);
    OrderDetailDO orderDetailDO = orderDetailDOS.stream().filter(item -> item.getSkuId().equals(skuId)).findFirst().orElse(null);
    OrderTypeEnum orderTypeEnum = OrderTypeEnum.getByCode(orderSubDO.getOrderType());
    switch (orderTypeEnum) {
        //实物订单
        case DEFAULT:
            return orderDetailDO.getPrice();
        //卡券订单
        case COUPON:
            return orderDetailDO.getPrice().multiply(new BigDecimal("1.1"));
        //会员订单
        case VIP:
            return orderDetailDO.getPrice().multiply(new BigDecimal("0.9"));
        default:
            return null;
    }
}

        实物订单的商品取原价，卡券订单的商品取原价*1.1，会员订单的商品取原价*0.9。上面只是一个简单实现的demo，计算价格的代码只有一行。而如果计算订单商品价格的逻辑比较复杂的话，这个方法将会变得异常臃肿，而且也不利于扩展。

        这个时候我们就可以使用策略模式来进行重构，不同计算商品价格的逻辑会抽象出一个策略类来。

抽象策略（Abstract Strategy）：通常由一个接口或一个抽象类实现，里面定义了一些抽象的规范；
具体策略（Concrete Strategy）：具体的算法和行为；
环境（Context）：持有策略类的应用，负责将客户端请求委派给具体的策略对象执行。        

        通常我们在遇到有多个分支的代码，可以抽象成统一的调度层的时候，可以考虑使用策略模式来实现。

---

2 示例

        再举个例子，假如说现在需要实现一个支付的功能，因为支付有很多的接入渠道（微信支付、支付宝、XX银行等等），每种渠道又可以抽象出相同的支付功能，所以很适合用策略模式来实现。

        首先需要实现一个枚举：

public enum PayEnum {

    WECHAT_PAY(1, "微信支付"),
    ALIPAY(2, "支付宝支付"),
    BANK(3, "XX银行支付");

    private final Integer code;
    private final String  desc;

    PayEnum(Integer code, String desc) {
        this.code = code;
        this.desc = desc;
    }

    public Integer getCode() {
        return code;
    }

    public String getDesc() {
        return desc;
    }

    public static PayEnum getByCode(Integer code) {
        return Arrays.stream(values()).filter(item -> item.getCode().equals(code)).findFirst().orElse(null);
    }
}

        接着写一个支付抽象类：

public abstract class AbstractPay {

    public abstract PayEnum type();

    /**
     * 预支付
     */
    public abstract String prePay();

    /**
     * 支付
     */
    public abstract String pay();
}

        分别实现微信支付、支付宝支付和银行支付：

@Service
public class WechatPay extends AbstractPay {

    @Override
    public PayEnum type() {
        return PayEnum.WECHAT_PAY;
    }

    @Override
    public String prePay() {
        return "微信预支付";
    }

    @Override
    public String pay() {
        return "微信支付";
    }
}

@Service
public class AliPay extends AbstractPay {

    @Override
    public PayEnum type() {
        return PayEnum.ALIPAY;
    }

    @Override
    public String prePay() {
        return "支付宝预支付";
    }

    @Override
    public String pay() {
        return "支付宝支付";
    }
}

@Service
public class BankPay extends AbstractPay {

    @Override
    public PayEnum type() {
        return PayEnum.BANK;
    }

    @Override
    public String prePay() {
        return "XX银行预支付";
    }

    @Override
    public String pay() {
        return "XX银行支付";
    }
}

        为了便于演示，这里具体的支付实现就用打印一句话来代替了。

        有了具体的支付实现后，我们还需要一个工厂类：

@Component
public class PayFactory {

    public AbstractPay getStrategy(Integer code) {
        PayEnum payEnum = PayEnum.getByCode(code);
        if (payEnum == null) {
            return null;
        }
        switch (payEnum) {
            case WECHAT_PAY:
                return new WechatPay();
            case ALIPAY:
                return new AliPay();
            case BANK:
                return new BankPay();
            default:
                return null;
        }
    }
}

        这样我们就可以通过调用PayFactory.getStrategy方法来获取到相应的策略类，之后再调用相应的支付方法就行了。不需要去理解每种策略的实现，只需要传入支付类型即可。

        但是上面的工厂类实现还有个问题：如果策略有很多，并且会频繁更改的话，那么每次都需要新加一种case条件，这样不利于扩展。我们只是把if-else条件挪到了工厂类里面而已，并没有发生实质性的变化，该改的还是会改。所以这里我们改造一下，利用Spring相关的功能进行重构：

@Component
public class PayConfig implements InitializingBean {

    @Autowired
    private ApplicationContext applicationContext;

    private static final Map<PayEnum, AbstractPay> STRATEGY_MAP = Maps.newHashMapWithExpectedSize(3);

    @Override
    public void afterPropertiesSet() {
        Map<String, AbstractPay> beans = applicationContext.getBeansOfType(AbstractPay.class);
        for (Map.Entry<String, AbstractPay> entry : beans.entrySet()) {
            AbstractPay bean = entry.getValue();
            STRATEGY_MAP.put(bean.type(), bean);
        }
    }

    public AbstractPay getStrategy(PayEnum payEnum) {
        return STRATEGY_MAP.get(payEnum);
    }
}

        applicationContext.getBeansOfType方法可以动态获取到抽象类的所有实现类。而PayConfig实现了InitializingBean接口，在项目启动的时候会执行其中的afterPropertiesSet方法。该方法中会把所有的策略类缓存成一个map，之后在使用的时候直接调用PayConfig.getStrategy方法就行了。这样的话如果以后需要增加或删除策略类，也不需要更改PayConfig类中的代码，每次项目启动的时候都会重新获取当前最新的策略类。

        调用的demo如下所示：

AbstractPay strategy = payConfig.getStrategy(PayEnum.WECHAT_PAY);
String prePay = strategy.prePay();
String pay = strategy.pay();