大家好，今天跟大家聊聊工作中我们经常会遇到的问题。

上货！

废话不多说，那我们就直接开始吧。

小伙子，你在工作中用到过什么设计模式呢？

（这不又说到我心坎儿上来了吗？）面试官你好，是这样的，我在工作中用到过和接触到过的设计模式有单例模式，工厂模式，代理模式，责任链模式，策略模式...balabala

那你跟我讲一讲策略模式吧

开闭原则

嗯好，是这样的，说到策略模式的话，我们就不得不聊一聊七大软件架构设计原则之开闭原则了。顾名思义呢，开闭原则是指一个软件实体，比如一个类或者说对象，它应该是对扩展开放的，对修改关闭的。所谓开闭，也是对扩展和修改两个行为的一个原则。

简单来说呢，我们的代码更新迭代的过程中，尽可能的不去修改我们的源码，而是去增加我们的新的代码。

策略模式的应用场景

策略模式会在什么场景下使用？

有大概三种应用场景吧

• 针对同一类型问题，有多种处理方式，每一种都能独立解决问题。（例如在线支付的支付方式）
• 需要自由切换算法的场景（例如汇率计算，不同场景下的税务计算）
• 需要屏蔽算法规则的场景

那策略模式跟开闭原则有什么关系呢？

策略模式使用的就是面向对象的继承和多态机制，从而实现同一行为在不同的场景下具备不同的实现。也就是说我们需要针对同一个行为，比如付款，在不同的场景，比如微信和支付宝这样不同的场景下，会有不同的实现方式。日常的情况下，我们会通过if-else或者switch-case的语句来处理这样的逻辑。如果在不受开闭原则的限制下，我们这样写是没有问题的。

那为什么不可以这样写？

（哟，鱼儿上钩了，这不就闭环了吗？）

我们在设计代码的时候要遵循开闭原则，是因为在软件设计之初，可能想法不够完善，后续存在修改的可能性。那么在这样的条件下，还是刚刚那个例子，在使用if-else或者switch-case就不遵循开闭原则，那后期需求是需要增加一种或者多种新的支付方式，比如银行卡支付，那我们是不是又要在修改原来的代码文件？是不是需要增加if语句？或者说增加case语句？这就违反了开闭原则了。反而如果我们一开始就使用策略模式来设计，就不需要修改源代码。

那使用策略模式应该怎么做呢？

策略模式的具体实现

那还是按照刚刚说的那个例子，要使用策略模式实现:

我们首先需要定一个顶层接口支付方式。

public interface Payment {
    void pay(Pay pay);
}
复制代码

当然还有我们的支付对象的定义，以及其中的枚举定义:

public class Pay {
    private PaymentType paymentType;

    public PaymentType getPaymentType() {
        return paymentType;
    }
?
    public void setPaymentType(PaymentType paymentType) {
        this.paymentType = paymentType;
    }
}
?
public enum PaymentType {
    ALI_PAY("AliPayment"),
    WECHAT_PAY("WechatPaymet");
?
    private String type;
?
    private PaymentType(String type){
        this.setType(type);
    }
?
    private String getType() {
        return type;
    }
?
    private void setType(String type) {
        this.type = type;
    }
}
复制代码

再定义两个不同的支付方式

@PaymentTypes(paymentType = PaymentType.ALI_PAY)
public class AliPayment implements Payment {
    @Override
    public void pay(Pay pay) {
        //ali payment logic.
    }
}
?
?
@PaymentTypes(paymentType = PaymentType.WECHAT_PAY)
public class WechatPayment implements Payment {
    @Override
    public void pay(Pay pay) {
        //we chat payment logic.
    }
}
复制代码

同时我们设计一个注解来表示当前支付方式是哪一种，以便于使用的时候判断:

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE})
//注解标志支付方式
public @interface PaymentTypes {
    PaymentType paymentType();
}
复制代码

那么关键在于遵循实现开闭原则，当需要新增一种支付方式的时候，如何做到不修改源代码的情况下增加一种支付策略，那我们就在定义一种工厂，此工厂可以提供所有的支付方式:

public class AutoRegisterPaymentFactory implements ApplicationContextAware, InitializingBean {
?
    private ApplicationContext applicationContext;
?
    //全局map，key为支付方式，value为支付方式对应的实现类
    static Map<PaymentType, Payment> paymentMap = new HashMap<>();
?
    static Map<String, Payment> beanMap = new HashMap<>();
    
    //获取当前支付方式的实现类
    public static Payment getPayment(PaymentType paymentType) throws Exception {
        if(paymentMap.containsKey(paymentType)) {
            return paymentMap.get(paymentType);
        } else {
            throw new Exception("this kind of payment not support");
        }
    }
?
    @Override
    public void afterPropertiesSet() throws Exception {
        //获取所有的支付方式实现类
        beanMap = applicationContext.getBeansOfType(Payment.class);
        List<Payment> paymentList = beanMap.values().stream().collect(Collectors.toList());
        if(!CollectionUtils.isEmpty(paymentList)) {
            for (Payment payment : paymentList) {
                //读取实现类的注解，获取实现类的类型
                if(payment.getClass().isAnnotationPresent(PaymentTypes.class)) {
                    PaymentTypes paymentTypes = payment.getClass().getAnnotation(PaymentTypes.class);
                    PaymentType paymentType = paymentTypes.paymentType();
                    //加入全局map，完成支付方式自动注册
                    paymentMap.put(paymentType,payment);
                }
            }
        }
    }
?
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}
复制代码

同时，那调用模式就变成下面这样了:

public static void main(String args[]) throws Exception {
    Pay aliPay = new Pay();
    aliPay.setPaymentType(PaymentType.ALI_PAY);
    //自动注册
    AutoRegisterPaymentFactory autoRegisterPaymentFactory = new AutoRegisterPaymentFactory();
    //获取当前支付类型下的实现类
    Payment payment = AutoRegisterPaymentFactory.getPayment(aliPay.getPaymentType());
    //调用实现类的业务逻辑
    payment.pay(aliPay);
}
复制代码

那通过上面的策略模式的实现方式呢，如果要添加一个支付方式，我们只需要新增一个实现类，并加上支付方式的注解，并在原有的枚举类中添加这个新的支付方式枚举就可以了，无需修改原有的任何业务逻辑。

对了，在自动注册这个工厂中，也可以通过反射的方式去获取实现类。

那面试官，我讲完了，您有什么疑问吗？（反将一军！）

那使用策略模式有什么缺点呢？

（就离谱！这也能问出来？）

咳咳...是这样的，通过我们刚刚的聊天您也看到了，我水没喝两口，嘴上可没停啊。这就是策略模式的第一个缺点：代码中会产生相当多的策略类，增加维护的难度。也就是说，每一种实现方式都会有一个对应的实现类，而区别与非策略模式的代码，一个service中可以将不同的策略写为不同的方法，但是策略模式下就显得实现类特别多，当前提交文件也多，code review要看的也多......

同时呢，我们客户端必须知道所有的策略，并且自行决定使用哪一个策略类。以上呢，就是我觉得可能存在的一些不足。但是双刃剑嘛，我们得到了遵循开闭原则的代码，降低了if-else的可能的圈复杂度，同时，还可以提高算法的保密性和安全性，使用哪个？自己掂量掂量吧。

看来你基础还不错，接下来再聊聊...

后记

写这个文章呢，是因为我在实际工作中确实遇到了不少类似的场景，后期需要修改原需求的需求也见的不少，所以想着干脆就写下来吧。

以后我会继续把其他的设计模式也继续更下去

如果有帮到你，万分荣幸！

原文链接：https://juejin.cn/post/7154715912312979463