策略模式是oop中最著名的设计模式之一，是对方法行为的抽象，可以归类为行为设计模式，也是oop中interface经典的应用。其特点简单又实用，是我最喜欢的模式之一。策略模式定义了一个拥有共同行为的算法族，每个算法都被封装起来，可以互相替换，独立于客户端而变化。策略模式本身的实现比较简单，但是结合单例模式+简单工厂模式+注解+反射，可以构造出近乎完善的策略模式，彻底的消除if-else。
一、策略模式基础
策略模式是oop中最著名的设计模式之一，是对方法行为的抽象，可以归类为行为设计模式，也是oop中interface经典的应用。其特点简单又实用，是我最喜欢的模式之一。策略模式定义了一个拥有共同行为的算法族，每个算法都被封装起来，可以互相替换，独立于客户端而变化。
我们可以从三个方面来理解策略模式：
- 算法族
使用多种不同的处理方式，做同样的事情，仅仅是具体行为有差别。这些处理方式，组合构成算法策略族，它们的共性，体现在策略接口行为上。 - 算法封装
将各个算法封装到不同的类中，这样有助于客户端来选择合适的算法。 - 可互相替换
客户端可以在运行时选择使用哪个算法，而且算法可以进行替换，所以客户端依赖于策略接口。
据此，可以推断出策略模式的使用场景：
- 针对同一问题的多种处理方式，仅仅是具体行为有差别时；
- 需要安全地封装多种同一类型的操作时；
- 同一抽象类有多个子类，而客户端需要使用 if-else 或者 switch-case 来选择具体子类时。
策略模式UML类图如下：
image
可以看到策略模式涉及到三个角色：
环境(Context)角色：持有一个Strategy的引用。
抽象策略(Strategy)角色：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。
具体策略(ConcreteStrategy)角色：包装了相关的具体算法或行为。
策略模式典型代码如下：
/// <summary>
/// 抽象策略类（接口）
/// </summary>
public interface Strategy
{
/// <summary>
/// 抽象策略方法
/// </summary>
void StrategyFunc();
}
/// <summary>
/// 具体策略类A
/// </summary>
public class ConcreteStrategyA : Strategy
{
public void StrategyFunc()
{
//具体方法A
}
}
/// <summary>
/// 具体策略类B
/// </summary>
public class ConcreteStrategyB : Strategy
{
public void StrategyFunc()
{
//具体方法B
}
}
/// <summary>
/// 具体策略类C
/// </summary>
public class ConcreteStrategyC : Strategy
{
public void StrategyFunc()
{
//具体方法C
}
}
/// <summary>
/// 环境
/// </summary>
public class Context
{
//持有一个具体策略的对象
private Strategy _strategy;
/// <summary>
/// 构造函数，传入一个具体策略对象
/// </summary>
/// <param name="strategy"></param>
public Context(Strategy strategy)
{
this._strategy = strategy;
}
/// <summary>
/// 调用策略方法
/// </summary>
public void ContextFunc()
{
_strategy.StrategyFunc();
}
}
/// <summary>
/// 客户端调用
/// </summary>
public class Client
{
public void Main(string param)
{
Context context;
if (param == "A")
{
context = new Context(new ConcreteStrategyA());
}
else if(param == "B")
{
context = new Context(new ConcreteStrategyB());
}
else if(param == "C")
{
context = new Context(new ConcreteStrategyC());
}
else
{
throw new Exception("没有可用的策略");
}
context.ContextFunc();
}
}
二、策略模式实例-会员策略
假设某店家推出三种会员，分别为普通会员，金牌会员和钻石会员，还有就是普通顾客，针对不同的会员顾客，购物结算时有不同的打折方式。购物后，客户的历史购物金额累计，可以自动升级到相应的会员级别。
这里的购物结算时，我们就很适宜使用策略模式，因为策略模式描述的就是算法的不同。这里举例我们就采用简单的方式，四类顾客分别采用原价（非会员普通顾客），九折、八折、七折的收钱方式。
那么我们首先要有一个计算价格的策略接口：
/// <summary>
/// Vip算法规则
/// </summary>
public interface IVipAlgorithm
{
int CalcPrice(int originalPrice);
}
然后下面是不同会员顾客的收钱算法的具体实现：
public enum Vip
{
普通会员 = 1,
黄金会员 = 2,
钻石会员 = 3
}
/// <summary>
/// 非会员顾客
/// </summary>
public class VipNone : IVipAlgorithm
{
public int CalcPrice(int originalPrice)
{
return originalPrice;
}
}
/// <summary>
/// 普通会员
/// </summary>
public class VipOrdinary : IVipAlgorithm
{
public int CalcPrice(int orginalPrice)
{
var currentPrice = (int)(orginalPrice * 0.9 + 0.5);
return currentPrice;
}
}
/// <summary>
/// 金牌会员
/// </summary>
public class VipGold : IVipAlgorithm
{
public int CalcPrice(int orginalPrice)
{
var currentPrice = (int)(orginalPrice * 0.8 + 0.5);
return currentPrice;
}
}
/// <summary>
/// 钻石会员
/// </summary>
public class VipDiamond: IVipAlgorithm
{
public int CalcPrice(int orginalPrice)
{
var currentPrice = (int)(orginalPrice * 0.7 + 0.5);
return currentPrice;
}
}
接下来看顾客类，顾客类中自动累计历史购物金额，判断会员级别，进行打折结算。
public class Customer
{
public int _totalAmount = 0;
public Vip? _vip = null;
public IVipAlgorithm _vipAlgorithm;
public void Buy(decimal originPriceM)
{
if (_totalAmount >= 5000 * 100)
{
_vip = Vip.钻石会员;
_vipAlgorithm = new VipDiamond();
}
else if (_totalAmount >= 3000 * 100)
{
_vip = Vip.黄金会员;
_vipAlgorithm = new VipGold();
}
else if (_totalAmount >= 1000 * 100)
{
_vip = Vip.普通会员;
_vipAlgorithm = new VipOrdinary();
}
else
{
_vip = null;
_vipAlgorithm = new VipNone();
}
var originPrice = (int)originPriceM * 100;
var finalPrice = _vipAlgorithm.CalcPrice(originPrice);
//打印
Console.WriteLine($"您在本店历史消费总额：{_totalAmount * 0.01}元");
var vipMsg = _vip.HasValue ? $"您是本店会员：{_vip.Value.ToString()}" : "您未升级为本店会员";
Console.WriteLine(vipMsg);
Console.WriteLine($"本次购买商品原价{originPrice * 0.01}元，需支付{finalPrice * 0.01}元");
_totalAmount += originPrice;
Console.WriteLine();
}
}
最后是客户端调用，系统会帮我们自动调整结算打折策略。
class Program
{
static void Main(string[] args)
{
Customer cust = new Customer();
cust.Buy(1000);
cust.Buy(1000);
cust.Buy(1000);
cust.Buy(1000);
cust.Buy(1000);
cust.Buy(1000);
cust.Buy(1000);
Console.ReadLine();
}
}
输出结果：
image
可以看到随着此顾客购物金额累加，会员身份自动升级，购物结算折扣也越来越多。这样设计的好处显而易见，客户端不再依赖于具体的收费策略，依赖于抽象永远是正确的。
在上面的基础上，我们可以使用简单工厂来解耦顾客类的结算策略依赖。
public class VipAlgorithmFactory
{
private VipAlgorithmFactory() { }
//根据客户的总金额产生相应的策略
public static IVipAlgorithm GetVipAlgorithm(Customer cust, out Vip? vipLevel)
{
if (cust._totalAmount >= 5000 * 100)
{
vipLevel = Vip.钻石会员;
return new VipDiamond();
}
else if (cust._totalAmount >= 3000 * 100)
{
vipLevel = Vip.黄金会员;
return new VipGold();
}
else if (cust._totalAmount >= 1000 * 100)
{
vipLevel = Vip.普通会员;
return new VipOrdinary();
}
else
{
vipLevel = null;
return new VipNone();
}
}
}
这样就将制定策略的功能从客户类分离出来，我们的客户类可以变成这样。
public class Customer
{
public int _totalAmount = 0;
public Vip? _vip = null;
public IVipAlgorithm _vipAlgorithm;
public void Buy(decimal originPriceM)
{
//变化点，我们将策略的制定转移给了策略工厂，将这部分责任分离出去
_vipAlgorithm = VipAlgorithmFactory.GetVipAlgorithm(this,out this._vip);
var originPrice = (int)originPriceM * 100;
var finalPrice = _vipAlgorithm.CalcPrice(originPrice);
//
Console.WriteLine($"您在本店历史消费总额：{_totalAmount * 0.01}元");
var vipMsg = _vip.HasValue ? $"您是本店会员：{_vip.Value.ToString()}" : "您未升级为本店会员";
Console.WriteLine(vipMsg);
Console.WriteLine($"本次购买商品原价{originPrice * 0.01}元，需支付{finalPrice * 0.01}元");
_totalAmount += originPrice;
Console.WriteLine();
}
}
三、消除If-else
虽然结合简单工厂模式，我们的策略模式灵活了一些，但不免发现在工厂中仍然存在if-else判断，如果当我们增加一个会员级别，又得增加一个if-else语句，这是简单工厂的缺点，对修改开放。
那有什么方法，可以较好的解决这个问题呢？那就是使用注解，我们给策略类加上Vip级别注解，以根据Vip级别确定哪个策略生效，从而解决结算折扣策略选择的问题。另外在较复杂的系统中，我们还可以考虑使用IOC容器和依赖注入的方式来解决。这里只演示注解方式。
首先添加一个注解类，然后再为我们的每个策略类增加注解，如为钻石会员策略类增加注解[Vip(Vip.钻石会员)]。
public class VipAttribute : Attribute
{
public Vip Vip { get; set; }
public VipAttribute(Vip vip)
{
Vip = vip;
}
}
然后增加一个配置查询类，使用单例模式，避免每次访问都去实例化配置。
public class VipConfig
{
public readonly Dictionary<Vip, int> VipCondition;
public readonly Dictionary<Vip, IVipAlgorithm> VipAlgorithm;
private static VipConfig _vipConfigInstance;
private VipConfig()
{
//这里将配置硬编码到字典中，实际可以从配置文件中读取
VipCondition = new Dictionary<Vip, int> { { Vip.普通会员, 1000 * 100 }, { Vip.黄金会员, 3000 * 100 }, { Vip.钻石会员, 5000 * 100 } };
VipAlgorithm = Assembly.GetExecutingAssembly().GetExportedTypes()
.Select(t => new
{
Type = t,
Vip = t.GetCustomAttribute<VipAttribute>()?.Vip
})
.Where(x => x.Vip != null)
.ToDictionary(x => x.Vip.Value, x => (IVipAlgorithm)Activator.CreateInstance(x.Type));
}
public static VipConfig Instance
{
get
{
if (_vipConfigInstance == null)
{
_vipConfigInstance = new VipConfig();
}
return _vipConfigInstance;
}
}
}
策略工厂仍然帮我们自动找到适应的策略，现在将我们的工厂类调整如下：
public class VipAlgorithmFactory
{
public static IVipAlgorithm GetVipAlgorithm(Customer cust, out Vip? vipLevel)
{
var custVip = VipConfig.Instance.VipCondition.Where(x => x.Value <= cust._totalAmount)
.OrderByDescending(x => x.Value)
.ToList();
IVipAlgorithm vipAlgorithm = null;
if (custVip.Count == 0)
{
vipLevel = null;
vipAlgorithm = new VipNone();
}
else
{
vipLevel = custVip.First().Key;
vipAlgorithm = VipConfig.Instance.VipAlgorithm[vipLevel.Value];
}
return vipAlgorithm;
}
}
最终的顾客类相应调整如下：
public class Customer
{
public int _totalAmount = 0;
public Vip? _vip = null;
public IVipAlgorithm _vipAlgorithm;
public void Buy(decimal originPriceM)
{
_vipAlgorithm = VipAlgorithmFactory.GetVipAlgorithm(this, out this._vip);
var originPrice = (int)originPriceM * 100;
var finalPrice = _vipAlgorithm.CalcPrice(originPrice);
//
Console.WriteLine($"您在本店历史消费总额：{_totalAmount * 0.01}元");
var vipMsg = _vip.HasValue ? $"您是本店会员：{_vip.Value.ToString()}" : "您未升级为本店会员";
Console.WriteLine(vipMsg);
Console.WriteLine($"本次购买商品原价{originPrice * 0.01}元，需支付{finalPrice * 0.01}元");
_totalAmount += originPrice;
Console.WriteLine();
}
}
最终，通过单例、工厂、注解、反射共同配合，配置读取单例化，实现了更加完善的策略模式，消除了if-else。
四、总结
一，策略模式在.NET中的应用
在.NET Framework中也不乏策略模式的应用例子。例如，在.NET中，为集合类型ArrayList和List<T>提供的排序功能，其中实现就利用了策略模式，定义了IComparer接口来对比较算法进行封装，实现IComparer接口的类可以是顺序，或逆序地比较两个对象的大小，还可以使用快速排序，希尔排序，归并排序类等。具体.NET中的实现可以使用反编译工具查看List<T>.Sort(IComparer<T>)的实现。其中List<T>就是承担着环境角色，而IComparer<T>接口承担着抽象策略角色，具体的策略角色就是实现了IComparer<T>接口的类，List<T>类本身存在实现了该接口的类，我们可以自定义继承于该接口的具体策略类。
二，策略模式的优缺点
优点
- 易于扩展，增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码，符合开放封闭原则
- 避免使用多重条件选择语句，充分体现面向对象设计思想
- 策略类之间可以自由切换，由于策略类都实现同一个接口，所以使它们之间可以自由切换
- 每个策略类使用一个策略类，符合单一职责原则
- 客户端与策略算法解耦，两者都依赖于抽象策略接口，符合依赖反转原则
- 客户端不需要知道都有哪些策略类，符合最小知识原则
缺点
- 策略模式，当策略算法太多时，会造成很多的策略类
- 客户端不知道有哪些策略类，不能决定使用哪个策略类，这点可以通过本文中的方式解决，也可以考虑使用IOC容器和依赖注入的方式来解决
三，结论
策略模式、状态模式、责任链模式都是在解决if-else的问题，但目的不太一样。策略模式主要是对方法的封装，把一系列方法封装到一系列的策略类中，客户端可以根据不同情况选择使用适宜的策略类，不同的策略类可以自由切换。
策略模式除了在OOP中实践，也可以在FP中应用。OOP让我们以抽象设计的角度看系统，而FP让我们以简化设计的角度看系统，我们建议以OOP做第一阶段的重构，再辅以FP做第二阶段的重构，可以解决OOP容易过度设计的问题。在这里即可以进一步解决策略类过多的问题，比如策略接口可以退化为一个委托，或如Func<T1,T2>，C#向FP迈进，都是起源于委托的。然后策略类通常只有一个方法，所以真的有必要建立这么多类吗？完全可以退化为一个静态类加多个静态策略方法的形式，还有工厂类则从返回策略类实例变化为返回策略方法，这就是辅以FP思想重构C#策略模式的思路。
网友评论