一、开篇

　　上篇文章【大话设计模式】——简单工厂模式告诉了我们一个网吧收费工厂对象怎样创建收费形式（白天收费、夜间收费）的实例。简单工厂代码中有非常多
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）假设详细策略过多，会产生非常多的策略类，添加了维护的难度。

代码即人生啊~