设计模式之策略者模式

策略者模式简介

策略者模式定义一个算法接口，并由其实现类去实现，使得每一个算法都得到封装，并让他们可以相互替换。这是一种行为型模式。策略者模式降低了算法行为和环境角色的耦合度，使得算法可以独立发生变化。

策略者模式在现实世界的使用很多，比如互金场景中的优惠券模式，可以分为本金券，返现券，加息券，增收券等，每种卡券给予用户享受不同的权益，如果有一天增加了新的优惠券，也很容易扩展进去。由此可见，策略者模式使得业务线索更加清晰明了，每种业务线索场景彼此互不关联，互不影响。

同时，由于并不强耦合企业业务，所以当有一天企业业务扩大，并同时需要对卡券进行进一步的权益扩展的时候，修改起来也会很方便，当然某些可变数据是可以通过配置来解决的，这也进一步减少了代码的修改。
当然，我们也可以看到，根据特定的场景，充分运用其规则，并通过配合一些常规手段来进一步完善和稳定系统功能的时候，可以把设计模式的威力进一步发挥出来，切记不可拘泥于设计模式本身。

策略者模式UML类图

由UML类图可知策略者模式分为三个角色

Context：此处负责抽象策略类调度具体的算法策略，根据某些具体场景的不同，Context也可以有不同的实现。
Strategy：抽象算法策略类，所以具体策略者的父类，定义了一个抽象的方法，可以是接口也可以是抽象类，我一般使用抽象类，因为我需要对一些数据进行特殊的处理后再交给子类。
ConcreteStrategy：具体的算法策略，具体实现抽象的方法。

范例

以下范例，会使用前面所说的互金场景下的卡券，对于用户来说，就是购买产品时所使用的卡券能为自己带来多少收益，所以此处把【用】这个算法抽象出来，由每种卡券自己去实现响应的算法

策略算法抽象类：

 

public abstract class BaseCoupon
{
   protected int productCircle;

   public BaseCoupon(Product product)
   {
       productCircle = (product.EndTime - product.StartTime).Days;
   }

   public abstract decimal UseCoupon();
}

 

策略算法具体的四个卡券类

public class PrincipalCoupon : BaseCoupon
{
    public PrincipalCoupon(Product product) : base(product)
    {

    }

    /// <summary>
    /// 使用本金券
    /// </summary>
    /// <returns></returns>
    public override decimal UseCoupon()
    {
        Console.WriteLine($"此处使用的是本金券，产品周期{productCircle}，经计算将返现1.2元");

        return 1.2M;
    }
}

public class CashBackCoupon : BaseCoupon
{
    public CashBackCoupon(Product product) : base(product)
    {

    }

    /// <summary>
    /// 使用返现券
    /// </summary>
    public override decimal UseCoupon()
    {
        Console.WriteLine("此处使用的是返现券，产品周期{productCircle}，经计算将返现12元");

        return 12M;
    }
}

public class IncreaseInterestCoupon : BaseCoupon
{
    public IncreaseInterestCoupon(Product product) : base(product)
    {

    }

    /// <summary>
    /// 使用加息券
    /// </summary>
    public override decimal UseCoupon()
    {
        Console.WriteLine("此处使用的是加息券，产品周期{productCircle}，经计算将返现1.5元");

        return 1.5M;
    }
}

public class IncreaseIncome : BaseCoupon
{
    public IncreaseIncome(Product product) : base(product)
    {

    }

    /// <summary>
    /// 使用增收券
    /// </summary>
    public override decimal UseCoupon()
    {
        Console.WriteLine("此处使用的是增收券，产品周期{productCircle}，经计算将返现5.5元");

        return 5.5M;
    }
}

 

策略者上线文类，此处我提供了两种实现方式：

1、如果策略者上线文类比较简单，除了对象获取以外，没有其他特殊的使用，可以考虑类似于简单工厂的模式，毕竟，我们在开发卡券功能时，会提供相应的卡券类型枚举，此处可以借用一下

public class ConponUseContext
{
    public static BaseCoupon GetCoupon(CouponType couponType, Product product)
    {
        switch (couponType)
        {
            case CouponType.PrincipalCoupon:
                return new CashBackCoupon(product);

            case CouponType.CashBackCoupon:
                return new CashBackCoupon(product);

            case CouponType.IncreaseInterestCoupon:
                return new IncreaseInterestCoupon(product);

            case CouponType.IncreaseIncome:
                return new IncreaseIncome(product);

            default:
                throw new Exception("未知的卡券类型");
        }
    }
}

调用方式

   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、另外一种实现方式，就是采用注入方式，这种实现方式一般用于策略者上下文类功能比较多的情况

public class ConponUseContext
{
    private BaseCoupon baseCoupon;
    public ConponUseContext(BaseCoupon baseCoupon)
    {
        this.baseCoupon = baseCoupon;
    }

    public decimal UseCoupon()
    {
        return this.baseCoupon.UseCoupon();
    }
}

调用方式

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("我用了本金券");

        decimal interest = new ConponUseContext(new Product()).GetCoupon(CouponType.PrincipalCoupon);

        Console.WriteLine($"该用户获得的收益是{interest}");
    }
}

策略者模式优缺点

优点：

• 很好的体现了开闭原则，开发者可以在不变更其他具体算法的基础上新增新的策略类，即便是策略者的具体场景发生变化，并需要大规模修改时，也会很容易，因为独立的场景总会带来特定的思维模式，让开发者不会被其他场景所干扰，也就是所谓的关注点分离。
• 避免了大量的if-else
• 算法可以自由切换

缺点：

• 有可能会产生大量的策略类，并且所有策略类都会对外暴露

策略者模式使用场景思考

其实这一块我并不想写，因为写了以后，会给人一种思维定势，但是此处还是需要多讨论一下什么场景下去使用策略者模式，我们可以做一个这样的思考，当代码中或者即将编写的功能需要配合大量的if-else，其中的代码会较为复杂，并且这些产生if-else出现了较强的逻辑上的关联，外界也根本不关注其中的具体实现，在加入一层抽象层后，会使得这些功能更加聚合，更加明确，这个时候，可以考虑使用策略者模式。需要提醒的时候，策略者模式关注的是对象的行为，如果关注对象本身，可以使用简单工厂。