目录
1.策略模式定义
1.动机
- 软件构建过程中,某些对象使用的算法可能多种多样,经常改变,如果将这些算法都编码到对象中,将会使对象变得异常复杂;而且有时候支持不使用的算法也是一个性能负担。
- 如何在运行时根据需要透明地更改对象的算法?将算法与对象本身解耦,从而避免上述问题
2.模式定义
定义一系列算法,把它们一个个封装起来,并且使它们可互相替换(变化)。该模式使得算法可独立于使用它的客户程序(稳定)而变化(扩展,子类化)。——《设计模式》GoF
3.结构
标出来的红色部分是稳定的,蓝色部分是变化的。
在策略模式的结构图有以下角色:
(1)、环境角色(Context):持有一个Strategy类的引用。
需要使用ConcreteStrategy提供的算法。
内部维护一个Strategy的实例。
负责动态设置运行时Strategy具体的实现算法。
负责跟Strategy之间的交互和数据传递
(2)、抽象策略角色(Strategy):定义了一个公共接口,各种不同的算法以不同的方式实现这个接口,Context使用这个接口调用不同的算法,一般使用接口或抽象类实现。
(3)、具体策略角色(ConcreteStrategy):实现了Strategy定义的接口,提供具体的算法实现。
2.实现例子
1.问题描述
一个公司里,不同的人工作职责不同,领的薪水也不同,随着公司的不断扩大,后期还会组建其他的部门,招聘员工。
2.代码实现
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Pattern
{
/// <summary>
/// 抽象策略角色
/// </summary>
public interface IsalaryCaculator
{
//计算工资
void Caculator(double income);
}
//具体策略角色
/// <summary>
/// 普通职员
/// </summary>
public class normalsalaryCaculator : IsalaryCaculator
{
public void Caculator(double income)
{
//...
Console.WriteLine("普通职员的工资是{0}", income);
}
}
/// <summary>
/// CEO
/// </summary>
public class CEOsalaryCaculator : IsalaryCaculator
{
public void Caculator(double income)
{
//...
Console.WriteLine("CEO的工资是{0}", income*1.5);
}
}
/// <summary>
/// 开发人员
/// </summary>
public class ExploresalaryCaculator : IsalaryCaculator
{
public void Caculator(double income)
{
Console.WriteLine("开发人员的工资是{0}", income*1.3);
}
}
/// <summary>
/// 环境角色
/// </summary>
public class ContextSalary
{
private IsalaryCaculator _salaryCaculator;
public ContextSalary(IsalaryCaculator _salaryCaculator)
{
this._salaryCaculator = _salaryCaculator;
}
public IsalaryCaculator salaryCaculator
{
get { return _salaryCaculator; }
set { _salaryCaculator = value; }
}
public void GetSalary(double income)
{
_salaryCaculator.Caculator(income);
}
}
class Program
{
static void Main(string[] args)
{
ContextSalary context = new ContextSalary(new normalsalaryCaculator());
context.GetSalary(2000);
context.salaryCaculator = new CEOsalaryCaculator();
context.GetSalary(5000);
Console.ReadKey();
}
}
}
定义接口时,接口方法声明不需要添加public
3.要点总结
- Strategy机器子类为组件提供了一系列可重用的算法,从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换
- Strategy模式提供了用条件判断语句以外的另一种选择,消除条件判断语句,就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。
- 如果Strategy对象没有实例变量,那么各个上下文可以共享同一个Strategy对象,从而节省对象开销
优点:
- 策略类之间可以自由切换。由于策略类都实现同一个接口,所以使它们之间可以自由切换。
- 易于扩展。增加一个新的策略只需要添加一个具体的策略类即可,基本不需要改变原有的代码。
- 避免使用多重条件选择语句,充分体现面向对象设计思想。
缺点:
- 客户端必须知道所有的策略类,并自行决定使用哪一个策略类。这点可以考虑使用IOC容器和依赖注入的方式来解决,关于IOC容器和依赖注入(Dependency Inject)的文章可以参考:IoC 容器和Dependency Injection 模式。
- 策略模式会造成很多的策略类。
在下面的情况下可以考虑使用策略模式:
1】、一个系统需要动态地在几种算法中选择一种的情况下。那么这些算法可以包装到一个个具体的算法类里面,并为这些具体的算法类提供一个统一的接口。
2】、如果一个对象有很多的行为,如果不使用合适的模式,这些行为就只好使用多重的if-else语句来实现,此时,可以使用策略模式,把这些行为转移到相应的具体策略类里面,就可以避免使用难以维护的多重条件选择语句,并体现面向对象涉及的概念。