我正在参加「掘金·启航计划」
忽如一夜春风来，千树万树梨花开。
大家好，我是际遇，好久不见了，今天跟大家聊聊工作中我们经常会遇到的问题。
上货！
废话不多说，那我们就直接开始吧。
小伙子，你在工作中用到过什么设计模式呢？
（这不又说到我心坎儿上来了吗？）面试官你好，是这样的，我在工作中用到过和接触到过的设计模式有单例模式，工厂模式，代理模式，责任链模式，策略模式...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的可能的圈复杂度，同时，还可以提高算法的保密性和安全性，使用哪个？自己掂量掂量吧。
看来你基础还不错，接下来再聊聊...
后记
写这个文章呢，是因为我在实际工作中确实遇到了不少类似的场景，后期需要修改原需求的需求也见的不少，所以想着干脆就写下来吧。
以后我会继续把其他的设计模式也继续更下去
如果有帮到你，万分荣幸！
