策略模式是oop中最著名的设计模式之一,是对方法行为的抽象,可以归类为行为设计模式,也是oop中interface经典的应用。其特点简单又实用,是我最喜欢的模式之一。策略模式定义了一个拥有共同行为的算法族,每个算法都被封装起来,可以互相替换,独立于客户端而变化。策略模式本身的实现比较简单,但是结合单例模式+简单工厂模式+注解+反射,可以构造出近乎完善的策略模式,彻底的消除if-else。
策略模式是oop中最著名的设计模式之一,是对方法行为的抽象,可以归类为行为设计模式,也是oop中interface经典的应用。其特点简单又实用,是我最喜欢的模式之一。策略模式定义了一个拥有共同行为的算法族,每个算法都被封装起来,可以互相替换,独立于客户端而变化。策略模式本身的实现比较简单,但是结合单例模式+简单工厂模式+注解+反射,可以构造出近乎完善的策略模式,彻底的消除if-else。
一、策略模式基础
策略模式是oop中最著名的设计模式之一,是对方法行为的抽象,可以归类为行为设计模式,也是oop中interface经典的应用。其特点简单又实用,是我最喜欢的模式之一。策略模式定义了一个拥有共同行为的算法族,每个算法都被封装起来,可以互相替换,独立于客户端而变化。
我们可以从三个方面来理解策略模式:
- 算法族
使用多种不同的处理方式,做同样的事情,仅仅是具体行为有差别。这些处理方式,组合构成算法策略族,它们的共性,体现在策略接口行为上。 - 算法封装
将各个算法封装到不同的类中,这样有助于客户端来选择合适的算法。 - 可互相替换
客户端可以在运行时选择使用哪个算法,而且算法可以进行替换,所以客户端依赖于策略接口。
据此,可以推断出策略模式的使用场景:
- 针对同一问题的多种处理方式,仅仅是具体行为有差别时;
- 需要安全地封装多种同一类型的操作时;
- 同一抽象类有多个子类,而客户端需要使用 if-else 或者 switch-case 来选择具体子类时。
策略模式UML类图如下:
可以看到策略模式涉及到三个角色:
环境(Context)角色:持有一个Strategy的引用。
抽象策略(Strategy)角色:这是一个抽象角色,通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。
具体策略(ConcreteStrategy)角色:包装了相关的具体算法或行为。
策略模式典型代码如下:
1 /// <summary>
2 /// 抽象策略类(接口)
3 /// </summary>
4 public interface Strategy
5 {
6 /// <summary>
7 /// 抽象策略方法
8 /// </summary>
9 void StrategyFunc();
10 }
11 /// <summary>
12 /// 具体策略类A
13 /// </summary>
14 public class ConcreteStrategyA : Strategy
15 {
16 public void StrategyFunc()
17 {
18 //具体方法A
19 }
20 }
21 /// <summary>
22 /// 具体策略类B
23 /// </summary>
24 public class ConcreteStrategyB : Strategy
25 {
26 public void StrategyFunc()
27 {
28 //具体方法B
29 }
30 }
31 /// <summary>
32 /// 具体策略类C
33 /// </summary>
34 public class ConcreteStrategyC : Strategy
35 {
36 public void StrategyFunc()
37 {
38 //具体方法C
39 }
40 }
41 /// <summary>
42 /// 环境
43 /// </summary>
44 public class Context
45 {
46 //持有一个具体策略的对象
47 private Strategy _strategy;
48 /// <summary>
49 /// 构造函数,传入一个具体策略对象
50 /// </summary>
51 /// <param name="strategy"></param>
52 public Context(Strategy strategy)
53 {
54 this._strategy = strategy;
55 }
56 /// <summary>
57 /// 调用策略方法
58 /// </summary>
59 public void ContextFunc()
60 {
61 _strategy.StrategyFunc();
62 }
63 }
64 /// <summary>
65 /// 客户端调用
66 /// </summary>
67 public class Client
68 {
69 public void Main(string param)
70 {
71 Context context;
72 if (param == "A")
73 {
74 context = new Context(new ConcreteStrategyA());
75 }
76 else if(param == "B")
77 {
78 context = new Context(new ConcreteStrategyB());
79 }
80 else if(param == "C")
81 {
82 context = new Context(new ConcreteStrategyC());
83 }
84 else
85 {
86 throw new Exception("没有可用的策略");
87 }
88 context.ContextFunc();
89 }
90 }
View Code
二、策略模式实例-会员策略
假设某店家推出三种会员,分别为普通会员,金牌会员和钻石会员,还有就是普通顾客,针对不同的会员顾客,购物结算时有不同的打折方式。购物后,客户的历史购物金额累计,可以自动升级到相应的会员级别。
这里的购物结算时,我们就很适宜使用策略模式,因为策略模式描述的就是算法的不同。这里举例我们就采用简单的方式,四类顾客分别采用原价(非会员普通顾客),九折、八折、七折的收钱方式。
那么我们首先要有一个计算价格的策略接口:
1 /// <summary>
2 /// Vip算法规则
3 /// </summary>
4 public interface IVipAlgorithm
5 {
6 int CalcPrice(int originalPrice);
7 }
然后下面是不同会员顾客的收钱算法的具体实现:
1 public enum Vip
2 {
3 普通会员 = 1,
4 黄金会员 = 2,
5 钻石会员 = 3
6 }
1 /// <summary>
2 /// 非会员顾客
3 /// </summary>
4 public class VipNone : IVipAlgorithm
5 {
6 public int CalcPrice(int originalPrice)
7 {
8 return originalPrice;
9 }
10 }
1 /// <summary>
2 /// 普通会员
3 /// </summary>
4 public class VipOrdinary : IVipAlgorithm
5 {
6 public int CalcPrice(int orginalPrice)
7 {
8 var currentPrice = (int)(orginalPrice * 0.9 + 0.5);
9 return currentPrice;
10 }
11 }
1 /// <summary>
2 /// 金牌会员
3 /// </summary>
4 public class VipGold : IVipAlgorithm
5 {
6 public int CalcPrice(int orginalPrice)
7 {
8 var currentPrice = (int)(orginalPrice * 0.8 + 0.5);
9 return currentPrice;
10 }
11 }
1 /// <summary>
2 /// 钻石会员
3 /// </summary>
4 public class VipDiamond: IVipAlgorithm
5 {
6 public int CalcPrice(int orginalPrice)
7 {
8 var currentPrice = (int)(orginalPrice * 0.7 + 0.5);
9 return currentPrice;
10 }
11 }
接下来看顾客类,顾客类中自动累计历史购物金额,判断会员级别,进行打折结算。
1 public class Customer
2 {
3 public int _totalAmount = 0;
4 public Vip? _vip = null;
5 public IVipAlgorithm _vipAlgorithm;
6 public void Buy(decimal originPriceM)
7 {
8 if (_totalAmount >= 5000 * 100)
9 {
10 _vip = Vip.钻石会员;
11 _vipAlgorithm = new VipDiamond();
12 }
13 else if (_totalAmount >= 3000 * 100)
14 {
15 _vip = Vip.黄金会员;
16 _vipAlgorithm = new VipGold();
17 }
18 else if (_totalAmount >= 1000 * 100)
19 {
20 _vip = Vip.普通会员;
21 _vipAlgorithm = new VipOrdinary();
22 }
23 else
24 {
25 _vip = null;
26 _vipAlgorithm = new VipNone();
27 }
28 var originPrice = (int)originPriceM * 100;
29 var finalPrice = _vipAlgorithm.CalcPrice(originPrice);
30 //打印
31 Console.WriteLine($"您在本店历史消费总额:{_totalAmount * 0.01}元");
32 var vipMsg = _vip.HasValue ? $"您是本店会员:{_vip.Value.ToString()}" : "您未升级为本店会员";
33 Console.WriteLine(vipMsg);
34 Console.WriteLine($"本次购买商品原价{originPrice * 0.01}元,需支付{finalPrice * 0.01}元");
35 _totalAmount += originPrice;
36 Console.WriteLine();
37 }
38 }
最后是客户端调用,系统会帮我们自动调整结算打折策略。
1 class Program
2 {
3 static void Main(string[] args)
4 {
5 Customer cust = new Customer();
6 cust.Buy(1000);
7 cust.Buy(1000);
8 cust.Buy(1000);
9 cust.Buy(1000);
10 cust.Buy(1000);
11 cust.Buy(1000);
12 cust.Buy(1000);
13 Console.ReadLine();
14 }
15 }
输出结果:
可以看到随着此顾客购物金额累加,会员身份自动升级,购物结算折扣也越来越多。这样设计的好处显而易见,客户端不再依赖于具体的收费策略,依赖于抽象永远是正确的。
在上面的基础上,我们可以使用简单工厂来解耦顾客类的结算策略依赖。
1 public class VipAlgorithmFactory
2 {
3 private VipAlgorithmFactory() { }
4 //根据客户的总金额产生相应的策略
5 public static IVipAlgorithm GetVipAlgorithm(Customer cust, out Vip? vipLevel)
6 {
7 if (cust._totalAmount >= 5000 * 100)
8 {
9 vipLevel = Vip.钻石会员;
10 return new VipDiamond();
11 }
12 else if (cust._totalAmount >= 3000 * 100)
13 {
14 vipLevel = Vip.黄金会员;
15 return new VipGold();
16 }
17 else if (cust._totalAmount >= 1000 * 100)
18 {
19 vipLevel = Vip.普通会员;
20 return new VipOrdinary();
21 }
22 else
23 {
24 vipLevel = null;
25 return new VipNone();
26 }
27 }
28 }
这样就将制定策略的功能从客户类分离出来,我们的客户类可以变成这样。
1 public class Customer
2 {
3 public int _totalAmount = 0;
4 public Vip? _vip = null;
5 public IVipAlgorithm _vipAlgorithm;
6 public void Buy(decimal originPriceM)
7 {
8 //变化点,我们将策略的制定转移给了策略工厂,将这部分责任分离出去
9 _vipAlgorithm = VipAlgorithmFactory.GetVipAlgorithm(this,out this._vip);
10 var originPrice = (int)originPriceM * 100;
11 var finalPrice = _vipAlgorithm.CalcPrice(originPrice);
12 //
13 Console.WriteLine($"您在本店历史消费总额:{_totalAmount * 0.01}元");
14 var vipMsg = _vip.HasValue ? $"您是本店会员:{_vip.Value.ToString()}" : "您未升级为本店会员";
15 Console.WriteLine(vipMsg);
16 Console.WriteLine($"本次购买商品原价{originPrice * 0.01}元,需支付{finalPrice * 0.01}元");
17 _totalAmount += originPrice;
18 Console.WriteLine();
19 }
20 }
三、消除If-else
虽然结合简单工厂模式,我们的策略模式灵活了一些,但不免发现在工厂中仍然存在if-else判断,如果当我们增加一个会员级别,又得增加一个if-else语句,这是简单工厂的缺点,对修改开放。
那有什么方法,可以较好的解决这个问题呢?那就是使用注解,我们给策略类加上Vip级别注解,以根据Vip级别确定哪个策略生效,从而解决结算折扣策略选择的问题。另外在较复杂的系统中,我们还可以考虑使用IOC容器和依赖注入的方式来解决。这里只演示注解方式。
首先添加一个注解类,然后再为我们的每个策略类增加注解,如为钻石会员策略类增加注解[Vip(Vip.钻石会员)]。
1 public class VipAttribute : Attribute
2 {
3 public Vip Vip { get; set; }
4 public VipAttribute(Vip vip)
5 {
6 Vip = vip;
7 }
8 }
然后增加一个配置查询类,使用单例模式,避免每次访问都去实例化配置。
1 public class VipConfig
2 {
3 public readonly Dictionary<Vip, int> VipCondition;
4 public readonly Dictionary<Vip, IVipAlgorithm> VipAlgorithm;
5 private static VipConfig _vipConfigInstance;
6 private VipConfig()
7 {
8 //这里将配置硬编码到字典中,实际可以从配置文件中读取
9 VipCondition = new Dictionary<Vip, int> { { Vip.普通会员, 1000 * 100 }, { Vip.黄金会员, 3000 * 100 }, { Vip.钻石会员, 5000 * 100 } };
10 VipAlgorithm = Assembly.GetExecutingAssembly().GetExportedTypes()
11 .Select(t => new
12 {
13 Type = t,
14 Vip = t.GetCustomAttribute<VipAttribute>()?.Vip
15 })
16 .Where(x => x.Vip != null)
17 .ToDictionary(x => x.Vip.Value, x => (IVipAlgorithm)Activator.CreateInstance(x.Type));
18 }
19 public static VipConfig Instance
20 {
21 get
22 {
23 if (_vipConfigInstance == null)
24 {
25 _vipConfigInstance = new VipConfig();
26 }
27 return _vipConfigInstance;
28 }
29 }
30 }
策略工厂仍然帮我们自动找到适应的策略,现在将我们的工厂类调整如下:
1 public class VipAlgorithmFactory
2 {
3 public static IVipAlgorithm GetVipAlgorithm(Customer cust, out Vip? vipLevel)
4 {
5 var custVip = VipConfig.Instance.VipCondition.Where(x => x.Value <= cust._totalAmount)
6 .OrderByDescending(x => x.Value)
7 .ToList();
8 IVipAlgorithm vipAlgorithm = null;
9 if (custVip.Count == 0)
10 {
11 vipLevel = null;
12 vipAlgorithm = new VipNone();
13 }
14 else
15 {
16 vipLevel = custVip.First().Key;
17 vipAlgorithm = VipConfig.Instance.VipAlgorithm[vipLevel.Value];
18 }
19 return vipAlgorithm;
20 }
21 }
最终的顾客类相应调整如下:
1 public class Customer
2 {
3 public int _totalAmount = 0;
4 public Vip? _vip = null;
5 public IVipAlgorithm _vipAlgorithm;
6 public void Buy(decimal originPriceM)
7 {
8 _vipAlgorithm = VipAlgorithmFactory.GetVipAlgorithm(this, out this._vip);
9 var originPrice = (int)originPriceM * 100;
10 var finalPrice = _vipAlgorithm.CalcPrice(originPrice);
11 //
12 Console.WriteLine($"您在本店历史消费总额:{_totalAmount * 0.01}元");
13 var vipMsg = _vip.HasValue ? $"您是本店会员:{_vip.Value.ToString()}" : "您未升级为本店会员";
14 Console.WriteLine(vipMsg);
15 Console.WriteLine($"本次购买商品原价{originPrice * 0.01}元,需支付{finalPrice * 0.01}元");
16 _totalAmount += originPrice;
17 Console.WriteLine();
18 }
19 }
最终,通过单例、工厂、注解、反射共同配合,配置读取单例化,实现了更加完善的策略模式,消除了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#策略模式的思路。
C# 1.0主要是OOP,C# 2.0主要是泛型,C# 3.0之后主要是FP部分,如Lambda、Linq,C# 也是在3.0开始与Java分道扬镳,朝向OOP+FP双hybrid语言目标推进,尤其到C# 7.0非常明显,如Tuple、Descontruction、Pattern Matching、Local Function...都是FP语言基本的机制。
完整的示例代码已放置于 https://github.com/gitsongs/StrategyPattern