策略者模式简介
策略者模式定义一个算法接口，并由其实现类去实现，使得每一个算法都得到封装，并让他们可以相互替换。这是一种行为型模式。策略者模式降低了算法行为和环境角色的耦合度，使得算法可以独立发生变化。
策略者模式在现实世界的使用很多，比如互金场景中的优惠券模式，可以分为本金券，返现券，加息券，增收券等，每种卡券给予用户享受不同的权益，如果有一天增加了新的优惠券，也很容易扩展进去。由此可见，策略者模式使得业务线索更加清晰明了，每种业务线索场景彼此互不关联，互不影响。
同时，由于并不强耦合企业业务，所以当有一天企业业务扩大，并同时需要对卡券进行进一步的权益扩展的时候，修改起来也会很方便，当然某些可变数据是可以通过配置来解决的，这也进一步减少了代码的修改。
当然，我们也可以看到，根据特定的场景，充分运用其规则，并通过配合一些常规手段来进一步完善和稳定系统功能的时候，可以把设计模式的威力进一步发挥出来，切记不可拘泥于设计模式本身。
策略者模式UML类图
由UML类图可知策略者模式分为三个角色
Context：此处负责抽象策略类调度具体的算法策略，根据某些具体场景的不同，Context也可以有不同的实现。
Strategy：抽象算法策略类，所以具体策略者的父类，定义了一个抽象的方法，可以是接口也可以是抽象类，我一般使用抽象类，因为我需要对一些数据进行特殊的处理后再交给子类。
ConcreteStrategy：具体的算法策略，具体实现抽象的方法。
范例
以下范例，会使用前面所说的互金场景下的卡券，对于用户来说，就是购买产品时所使用的卡券能为自己带来多少收益，所以此处把【用】这个算法抽象出来，由每种卡券自己去实现响应的算法
策略算法抽象类：
策略算法具体的四个卡券类
策略者上线文类，此处我提供了两种实现方式：
1、如果策略者上线文类比较简单，除了对象获取以外，没有其他特殊的使用，可以考虑类似于简单工厂的模式，毕竟，我们在开发卡券功能时，会提供相应的卡券类型枚举，此处可以借用一下
调用方式
2、另外一种实现方式，就是采用注入方式，这种实现方式一般用于策略者上下文类功能比较多的情况
调用方式
策略者模式优缺点
优点：
很好的体现了开闭原则，开发者可以在不变更其他具体算法的基础上新增新的策略类，即便是策略者的具体场景发生变化，并需要大规模修改时，也会很容易，因为独立的场景总会带来特定的思维模式，让开发者不会被其他场景所干扰，也就是所谓的关注点分离。
避免了大量的if-else
算法可以自由切换
缺点：
有可能会产生大量的策略类，并且所有策略类都会对外暴露
策略者模式使用场景思考
其实这一块我并不想写，因为写了以后，会给人一种思维定势，但是此处还是需要多讨论一下什么场景下去使用策略者模式，我们可以做一个这样的思考，当代码中或者即将编写的功能需要配合大量的if-else，其中的代码会较为复杂，并且这些产生if-else出现了较强的逻辑上的关联，外界也根本不关注其中的具体实现，在加入一层抽象层后，会使得这些功能更加聚合，更加明确，这个时候，可以考虑使用策略者模式。需要提醒的时候，策略者模式关注的是对象的行为，如果关注对象本身，可以使用简单工厂。
