动机（Motivation）

在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一种性能负担。

如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？

意图（Intent）

定义一系列算法，把它们一个个封装起来，并且使它们可以互相替换，该模式使得算法可以独立于使用它的客户而变化。

结构（Structure）

其中，

Context上下文：用一个ConcreteStrategy来配置，维护一个对Strategy对象的引用。

ConcreteStrategy具体策略类：封装了具体的算法或行为，继承于Strategy。

Strategy类：策略类，定义多有支持的算法的公共接口。

代码实现

Strategy类，定义所有支持的算法的公共接口，其中提供一个算法的抽象方法

    abstract class Strategy
    {
        public abstract void AlgorithmInterface();
    }

ConcreteStrategy类，封装了具体的算法或行为，继承于Strategy，下面是具体算法A，具体算法B的代码与A相同，都是重写Strategy抽象类中定义的抽象方法

    class ConcreteStrategyA : Strategy
    {
        public override void AlgorithmInterface()
        {
            Console.WriteLine("算法A实现");
        }
    }

Context上下文,用一个ConcreteStrategy来配置，维护一个对Strategy对象的引用

    class Context
    {
        Strategy strategy;
        //初始化时，传入具体的策略对象
        public Context(Strategy strategy)
        {
            this.strategy = strategy;
        }
        //上下文接口,根据具体的策略对象，调用其算法的方法
        public void ContextInterface()
        {
            strategy.AlgorithmInterface();
        }
    }

客户端代码

首先先实例化一个上下文

Context context;

实例化不同的具体策略，在调用 context.ContextInterface()的时候，我们获得的结果也会不一样

实例化策略A

context = new Context(new ConcreteStrategyA());
context.ContextInterface();

实例化策略B

context = new Context(new ConcreteStrategyB());
context.ContextInterface();

优点

1.策略模式提供了一个算法族，恰当使用继承可以把公共的代码转移到父类里面，从而避免重复的代码。

2.对客户隐藏具体策略（算法）的实现细节，彼此完全独立。

缺点

1.策略模式要求客户知道所有算法策略类，以便做出正确的选择。

2.策略模式中有很多策略类，每增加一种算法策略，就会产生一个新的策略类。可以把策略类设计成共享的，这样策略类可以被不同的客户端使用。