设计模式之策略者模式
策略者模式简介
策略者模式定义一个算法接口，并由其实现类去实现，使得每一个算法都得到封装，并让他们可以相互替换。这是一种行为型模式。策略者模式降低了算法行为和环境角色的耦合度，使得算法可以独立发生变化。
策略者模式在现实世界的使用很多，比如互金场景中的优惠券模式，可以分为本金券，返现券，加息券，增收券等，每种卡券给予用户享受不同的权益，如果有一天增加了新的优惠券，也很容易扩展进去。由此可见，策略者模式使得业务线索更加清晰明了，每种业务线索场景彼此互不关联，互不影响。
同时，由于并不强耦合企业业务，所以当有一天企业业务扩大，并同时需要对卡券进行进一步的权益扩展的时候，修改起来也会很方便，当然某些可变数据是可以通过配置来解决的，这也进一步减少了代码的修改。 当然，我们也可以看到，根据特定的场景，充分运用其规则，并通过配合一些常规手段来进一步完善和稳定系统功能的时候，可以把设计模式的威力进一步发挥出来，切记不可拘泥于设计模式本身。
策略者模式UML类图
由UML类图可知策略者模式分为三个角色
Context：此处负责抽象策略类调度具体的算法策略，根据某些具体场景的不同，Context也可以有不同的实现。 Strategy：抽象算法策略类，所以具体策略者的父类，定义了一个抽象的方法，可以是接口也可以是抽象类，我一般使用抽象类，因为我需要对一些数据进行特殊的处理后再交给子类。 ConcreteStrategy：具体的算法策略，具体实现抽象的方法。
范例
以下范例，会使用前面所说的互金场景下的卡券，对于用户来说，就是购买产品时所使用的卡券能为自己带来多少收益，所以此处把【用】这个算法抽象出来，由每种卡券自己去实现响应的算法
策略算法抽象类：
1: public abstract class BaseCoupon 2: { 3: protected int productCircle; 4: 5: public BaseCoupon(Product product) 6: { 7: productCircle = (product.EndTime - product.StartTime).Days; 8: } 9: 10: public abstract decimal UseCoupon(); 11: }策略算法具体的四个卡券类
1: public class PrincipalCoupon : BaseCoupon 2: { 3: public PrincipalCoupon(Product product) : base(product) 4: { 5: 6: } 7: 8: /// <summary> 9: /// 使用本金券 10: /// </summary> 11: /// <returns></returns> 12: public override decimal UseCoupon() 13: { 14: Console.WriteLine($"此处使用的是本金券，产品周期{productCircle}，经计算将返现1.2元"); 15: 16: return 1.2M; 17: } 18: } 19: 20: public class CashBackCoupon : BaseCoupon 21: { 22: public CashBackCoupon(Product product) : base(product) 23: { 24: 25: } 26: 27: /// <summary> 28: /// 使用返现券 29: /// </summary> 30: public override decimal UseCoupon() 31: { 32: Console.WriteLine("此处使用的是返现券，产品周期{productCircle}，经计算将返现12元"); 33: 34: return 12M; 35: } 36: } 37: 38: public class IncreaseInterestCoupon : BaseCoupon 39: { 40: public IncreaseInterestCoupon(Product product) : base(product) 41: { 42: 43: } 44: 45: /// <summary> 46: /// 使用加息券 47: /// </summary> 48: public override decimal UseCoupon() 49: { 50: Console.WriteLine("此处使用的是加息券，产品周期{productCircle}，经计算将返现1.5元"); 51: 52: return 1.5M; 53: } 54: } 55: 56: public class IncreaseIncome : BaseCoupon 57: { 58: public IncreaseIncome(Product product) : base(product) 59: { 60: 61: } 62: 63: /// <summary> 64: /// 使用增收券 65: /// </summary> 66: public override decimal UseCoupon() 67: { 68: Console.WriteLine("此处使用的是增收券，产品周期{productCircle}，经计算将返现5.5元"); 69: 70: return 5.5M; 71: } 72: }策略者上线文类，此处我提供了两种实现方式：
1、如果策略者上线文类比较简单，除了对象获取以外，没有其他特殊的使用，可以考虑类似于简单工厂的模式，毕竟，我们在开发卡券功能时，会提供相应的卡券类型枚举，此处可以借用一下
1: public class ConponUseContext 2: { 3: public static BaseCoupon GetCoupon(CouponType couponType, Product product) 4: { 5: switch (couponType) 6: { 7: case CouponType.PrincipalCoupon: 8: return new CashBackCoupon(product); 9: 10: case CouponType.CashBackCoupon: 11: return new CashBackCoupon(product); 12: 13: case CouponType.IncreaseInterestCoupon: 14: return new IncreaseInterestCoupon(product); 15: 16: case CouponType.IncreaseIncome: 17: return new IncreaseIncome(product); 18: 19: default: 20: throw new Exception("未知的卡券类型"); 21: } 22: } 23: }调用方式
1: class Program 2: { 3: static void Main(string[] args) 4: { 5: Console.WriteLine("我用了本金券"); 6: 7: decimal interest = ConponUseContext.GetCoupon(CouponType.PrincipalCoupon, new Product()); 8: 9: Console.WriteLine($"该用户获得的收益是{interest}"); 10: } 11: }2、另外一种实现方式，就是采用注入方式，这种实现方式一般用于策略者上下文类功能比较多的情况
1: public class ConponUseContext 2: { 3: private BaseCoupon baseCoupon; 4: public ConponUseContext(BaseCoupon baseCoupon) 5: { 6: this.baseCoupon = baseCoupon; 7: } 8: 9: public decimal UseCoupon() 10: { 11: return this.baseCoupon.UseCoupon(); 12: } 13: }调用方式
1: class Program 2: { 3: static void Main(string[] args) 4: { 5: Console.WriteLine("我用了本金券"); 6: 7: decimal interest = new ConponUseContext(new Product()).GetCoupon(CouponType.PrincipalCoupon); 8: 9: Console.WriteLine($"该用户获得的收益是{interest}"); 10: } 11: }策略者模式优缺点
优点：
- 很好的体现了开闭原则，开发者可以在不变更其他具体算法的基础上新增新的策略类，即便是策略者的具体场景发生变化，并需要大规模修改时，也会很容易，因为独立的场景总会带来特定的思维模式，让开发者不会被其他场景所干扰，也就是所谓的关注点分离。
- 避免了大量的if-else
- 算法可以自由切换
缺点：
- 有可能会产生大量的策略类，并且所有策略类都会对外暴露
策略者模式使用场景思考
其实这一块我并不想写，因为写了以后，会给人一种思维定势，但是此处还是需要多讨论一下什么场景下去使用策略者模式，我们可以做一个这样的思考，当代码中或者即将编写的功能需要配合大量的if-else，其中的代码会较为复杂，并且这些产生if-else出现了较强的逻辑上的关联，外界也根本不关注其中的具体实现，在加入一层抽象层后，会使得这些功能更加聚合，更加明确，这个时候，可以考虑使用策略者模式。需要提醒的时候，策略者模式关注的是对象的行为，如果关注对象本身，可以使用简单工厂。
腾讯云开发者
