一、开篇
上篇文章【大话设计模式】——简单工厂模式告诉了我们一个网吧收费工厂对象怎样创建收费形式（白天收费、夜间收费）的实例。简单工厂代码中有非常多 case分支语句 ,假设我们还想填加收费的形式（比方会员收费啊，通宵收费啊），就须要修改工厂代码，每次维护和扩展都要花费非常多时间，另外修改非常easy造成纰漏（比方之前的白天收费形式，非常可能由于修改从多收钱或者少收钱），所以简单工厂模式非常不安全。
所以我们要把常常变化的代码抽象出来，做到业务逻辑和界面逻辑分开，仅仅有这样才干更加easy做到维护和扩展。
发现问题，解决这个问题，人类就这样一点一滴的进步着。
发现了简单工厂的不好，策略模式就诞生啦，人类真的是非常睿智！
（呱唧呱唧）
以下大家熟悉一下策略模式的定义：
策略模式（Strategy）:它定义了算法家族，分别封装起来。让她们之间能够互相替换。此模式让算法的变化。不会影响到使用算法的客户。
二、UML图
Context（环境类）：须要使用ConcreteStrategy的详细算法，维护一个对Strategy对象的引用，负责跟Strategy之间的交互和数据传递。
Strategy（抽象策略类）：定义全部支持的算法的公共接口。
Context使用这个接口来调用ConcreteStrategy算法。
ConcreteStrategy（详细策略类）：封装了详细的算法和行为，继承与Strategy.
图中含有两种关系。聚合和继承。
三、实例解析
比方我们填饱肚子的方式。有几个策略能够考虑：吃水果、吃蔬菜、吃馒头。
首先定义一个抽象类吃，然后让吃的形式：吃水果，吃蔬菜。吃馒头继承这个抽象吃类。再声明一个Context类，用来配置吃的方法，维护一个对Strategy对象的引用。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApplication7
{
class Program
{
static void Main(string[] args)//client代码
{
Context context;
context = new Context(new EatingFruit());//实例化不同的策略，调用的时候获得的结果就不同。
context.ContextInterface();
context = new Context(new EatingVegetables());
context.ContextInterface();
context = new Context(new EatingSteamBread());
context.ContextInterface();
}
}
abstract class EatStrategy//抽象吃法类
{
public abstract void Eat();
}
class EatingFruit:EatStrategy //详细吃法吃苹果
{
public override void Eat()
{
Console .WriteLine ("饿了吃苹果");
}
}
class EatingVegetables : EatStrategy//详细吃法吃蔬菜
{
public override void Eat()
{
Console .WriteLine ("吃蔬菜也不饿");
}
}
class EatingSteamBread : EatStrategy//详细吃法吃馒头
{
public override void Eat()
{
Console .WriteLine ("吃馒头也不错");
}
}
class Context//写策略环境类
{
EatStrategy eatstrategy;
public Context(EatStrategy eatstrategy)//初始化时，传入详细的策略对象
{
this.eatstrategy = eatstrategy;
}
//上下文接口
public void ContextInterface()//依据详细的策略对象，调用其算法的方法
{
eatstrategy.Eat();
}
}
}
四、总结
策略模式的长处：
1）全部的算法完毕同样的工作。仅仅是实现不同，它以同样的方式调用全部的算法，降低了各种算法类与使用算法类之间的耦合。
个人理解：无论是吃水果还是吃蔬菜，异或是吃馒头。都是为了填饱肚子。尽管形式不同，假设有的人挑食吃饭一定要吃菜加馒头才肯吃，那假设没有卖馒头的，你就要减肥啦~
2）策略模式Strategy类层次为Context定义了一系列的可供重用的算法和行为。
继承有助于析取出这些算法中的公共功能。
个人理解：把东西分类放置。使用的时候就更加easy找到。
3）简化了单元測试，由于每一个算法都有自己的类，能够通过自己的接口单独測试。
个人理解：有单独的类。就更easy满足单一职责原则。这样測试一个功能，数据假设不正确，直接就能划分出范围。
比方值日分为扫地和擦桌子。安排小明拖地，小红擦桌子。假设值完日了，地面还脏。那肯定就是小明干的不好呗（当然排除搞破坏的可能）。
可是假设你让两个人干活，又没有分配任务，那好了，挨罚就两个人一起做个伴吧！
4）算法封装在单独的类中。能够消除条件语句。为client减轻了压力。
个人理解：领导者假设负责一个非常庞大的project的话，那些琐事会让他局限于细节，而失去了把控能力。
缺点：
1）client必须知道全部的策略类，并自行决定使用哪个策略类。
2）Strategy和Context之间存在通信开销
3）假设详细策略过多，会产生非常多的策略类，添加了维护的难度。
代码即人生啊~