什么是策略模式？
比如说对象的某个行为，在不同场景中有不同的实现方式，这样就可以将这些实现方式定义成一组策略，每个实现类对应一个策略，在不同的场景就使用不同的实现类，并且可以自由切换策略。
策略模式结构图如下：
策略模式需要一个策略接口，不同的策略实现不同的实现类，在具体业务环境中仅持有该策略接口，根据不同的场景使用不同的实现类即可。
面向接口编程，而不是面向实现。
策略模式的优点：
1、干掉繁琐的 if、switch 判断逻辑；
2、代码优雅、可复用、可读性好；
3、符合开闭原则，扩展性好、便于维护；
策略模式的缺点：
1、策略如果很多的话，会造成策略类膨胀；
2、使用者必须清楚所有的策略类及其用途；
策略模式实战
举个实际的例子，XX 公司是做支付的，根据不同的客户类型会有不同的支付方式和支付产品，比如：信用卡、本地支付，而本地支付在中国又有微信支付、支付宝、云闪付、等更多其他第三方支付公司，这时候策略模式就派上用场了。
传统的 if/ else/ switch 等判断写法大家都会写，这里就不贴代码了，直接看策略模式怎么搞！
1、定义策略接口
定义一个策略接口，所有支付方式的接口。
策略接口：
/** * 支付接口 * @author: 栈长 * @from: 公众号Java技术栈 */ public interface IPayment { /** * 支付 * @param order * @return */ PayResult pay(Order order); }
订单信息类：
/** * 订单信息 * @author: 栈长 * @from: 公众号Java技术栈 */ @Data public class Order { /** * 金额 */ private int amount; /** * 支付类型 */ private String paymentType; }
返回结果类：
/** * @author: 栈长 * @from: 公众号Java技术栈 */ @Data @AllArgsConstructor public class PayResult { /** * 支付结果 */ private String result; }
2、定义各种策略
定义各种支付策略，微信支付、支付宝、云闪付等支付实现类都实现这个接口。
微信支付实现：
/** * 微信支付 * @author: 栈长 * @from: 公众号Java技术栈 */ @Service("WechatPay") public class WechatPay implements IPayment { @Override public PayResult pay(Order order) { return new PayResult("微信支付成功"); } }
支付宝实现：
/** * 支付宝 * @author: 栈长 * @from: 公众号Java技术栈 */ @Service("Alipay") public class Alipay implements IPayment { @Override public PayResult pay(Order order) { return new PayResult("支付宝支付成功"); } }
云闪付实现：
/** * 银联云闪付 * @author: 栈长 * @from: 公众号Java技术栈 */ @Service("UnionPay") public class UnionPay implements IPayment { @Override public PayResult pay(Order order) { return new PayResult("云闪付支付成功"); } }
这里我把所有支付方式类都用 @Service 注解生成 Bean 放入 Spring Bean 容器中了，在使用策略的时候就不用 new 支付对象了，可以直接使用 Bean，这样更贴近业务。Spring 基础教程就不介绍了，大家可以关注公众号Java技术栈，回复：spring，历史教程我都整理好了。
3、使用策略
有的文章使用了枚举、HashMap 的方式来根据策略名称映射策略实现类 ，这样是没有问题，但在使用了 Spring 框架的项目还是有点多此一举，完全可以发挥 Spring 框架的优势，使用 Bean 名称就能找到对应的策略实现类了。
参考示例代码如下：
/** * 支付服务 * @author: 栈长 * @from: 公众号Java技术栈 */ @RestController public class PayService { @Autowired private ApplicationContext applicationContext; /** * 支付接口 * @param amount * @param paymentType * @return */ @RequestMapping("/pay") public PayResult pay(@RequestParam("amount") int amount, @RequestParam("paymentType") String paymentType) { Order order = new Order(); order.setAmount(amount); order.setPaymentType(paymentType); // 根据支付类型获取对应的策略 bean IPayment payment = applicationContext.getBean(order.getPaymentType(), IPayment.class); // 开始支付 PayResult payResult = payment.pay(order); return payResult; } }
看示例代码，我并没有像策略模式结构图中那样新建一个 Context 类持有策略接口，那是标准的策略模式，其实道理是一样的，关键是怎么施放策略。
测试一下：
http://localhost:8080/pay?amount=8800&paymentType=WechatPay
测试 OK，传入不同的支付方式会调用不同的策略。
本节教程所有实战源码已上传到这个仓库：https://github.com/javastacks/javastack
策略模式在 JDK 中的应用
现在我们知道如何使用策略模式了，现在我们再看看 JDK 哪些地方运用了策略模式呢。
1、线程池中的拒绝策略
线程池的构造中有一个拒绝策略参数，默认是默认拒绝策略：
其实这就是一个策略接口：
下面有几种拒绝策略的实现：
image-20210329161322406
在创建线程池的时候，就可以传入不同的拒绝策略，这就是 JDK 中策略模式的经典实现了。
2、比较器
JDK 中大量使用了 Comparator 这个策略接口：
策略接口有了，但策略需要开发人员自己定。
集合排序我们比较熟悉的了，不同的排序规则其实就是不同的策略：
这个策略模式使用了函数式编程接口，比较规则使用匿名内部类或者 Lambda 表达式就搞定了，不需要每个规则定义一个实现类，这样就大量省略策略类了。
这个策略模式可能藏的比较深，但也是 JDK 中经典的策略模式的应用了。
不限于这两个，其实还有更多，你还知道别的么？欢迎留言分享……
所以说，策略模式就在你身边，你一直都在用，但可能没有发觉。。
总结
使用策略模式，我们可以轻松干掉大量的 if/ else，代码也更优雅，还能很灵活的扩展。
像本文中支付的案例，后面我们想添加、删除多少个支付方式都不用修改现有的代码，所以就不会影响现有的业务，真正做到对扩展开放，对修改关闭。
当然，完全干掉 if/ else 是不可能的，不能过度设计，不能为了使用设计模式而使用设计模式，否则适得其反。但是，我们每个程序员都需要掌握策略模式，做到在系统中灵活驾驭，这样才能写出更优雅、高质量的代码。
