什么是策略模式
策略模式说白了就是将if-else中的业务抽离成多个策略类，当我们想要扩展业务的时候只需要添加对应的策略类即可，无需更改service层的业务代码。
我们拿网关层需要根据各个地域进行特性拦截的业务为例，在不使用设计模式的前提下是这样写代码：
如果我们后续需要添加一个对于英国的选项呢？ 那就需要修改原本的service层业务代码了。
策略模式的作用就是构建一个易扩展的代码结构，使用策略类代替if-else。后续添加业务时只需要添加对应的策略类即可，无需修改service业务代码。
即当我们需要添加应用选项时，只需要新建一个策略类实例并实现策略定义接口即可。
策略模式优化代码的必要性
这里可能有小伙伴们会觉得这样明明是将简单问题复杂化了。在开发过程中，我明明只写几行if-else就能完事的事情，换成策略模式我要多写好多代码。还要写策略映射相关的代码等等。
确实，如果对于个人项目或者业务很简单的项目来说，盲目的崇尚设计模式基本上就是在耍流氓。但是代码量庞大、业务十分复杂的企业级项目来说，一部分业务会由多人负责，而且要考虑到如果让新人接手老项目能不能用更短的时间找到对应的代码位置的问题。这个我是有过亲身经历的，那可真是太刺激了~
封装策略模式
其实使用设计模式还有一个很难受的问题，就是栽树的前人需要付出比较多的工作量将设计模式的结构搭建好。就拿策略模式举例，每一种业务的策略模式都要重复去搭建策略结构，这是比较耗时间的。不知道你们愿不愿，反正我是不愿意无偿给后人栽树的哈哈。所以这也是一个技术leader应该考虑的问题-封装！！
那么接下来就展示一下我对于策略模式的一种封装，让开发者更简单的使用策略模式：
1.策略实例注解
定义一个策略实例注解，用来给策略的实现类做唯一标识使用。当然也可以直接使用beanName作为唯一标识，但是我感觉这样做其实会更灵活一点。首先是将唯一标识限制在了某个策略内部，而不是bean全局，而且可以直接使用字典表或枚举定义，可以更好的支持业务。
2.策略工厂
定义一个统一的策略工厂，所有的策略都注册到这个工厂中统一管理。这样的好处就是不需要根据每个业务去重复构建策略结构了。
3.注册器
4.获取器
应用策略模式
上面已经将策略模式封装好了，下面就是根据业务去更简单的使用策略模式。
1. 定义策略接口
2. 定义策略实现
3. 注册策略
Spring容器初始化完成后，注册当前业务的策略
当然，如果小伙伴们嫌手动注册比较麻烦的话，还有另一种思路：
再提供一个@StrategyDefinition(策略定义注解), 将这个注解应用到策略类上， 然后可以在编译阶段或Spring容器初始化完成后扫描被@StrategyDefinition声明的策略类。
但是我个人感觉手动声明对于项目工程而言更加的直白、可观。可以让开发者一眼就能看出当前工程中注册了那些策略。
4. 获取策略实例
致谢
更简单的使用策略模式章节已经展示完成了，这样封装后是不是使用的更加简单了!
有以下需求的小伙伴们参照可以封装一下：
- 团队中小伙伴们都拿差不多的薪资，凭什么要我费力气栽树让后人乘凉，而且这树栽的也体现不出来业务价值。
- 需要规范开发，但是担心开发人员能力参差不齐或编码风格不一致导致设计模式难以维护。
以上是我在工作和学习中的一点总结，期望得到各位大佬们宝贵的建议
