当一个特定的任务有多个算法，而客户端决定在运行时使用的实际实现时，使用策略模式。

来自wiki策略模式文章的UML图:

主要特点:

这是一种行为模式。 它是基于委派的。 它通过修改方法行为来改变对象的内容。 它用来在一系列算法之间切换。 它在运行时改变对象的行为。

参考这篇文章获得更多信息和现实世界的例子:

策略模式的真实例子

状态模式允许对象在其内部状态改变时改变其行为

来自wiki状态模式文章的UML图:

如果我们必须根据对象的状态来改变它的行为，我们可以在object中有一个状态变量，并使用If -else条件块来根据状态执行不同的操作。状态模式用于通过上下文和状态实现提供一种系统的、损失耦合的方式来实现这一点。

有关更多细节，请参阅这篇journaldev文章。

与资源制作和期刊开发文章的主要区别:

The difference between State and Strategy lies with binding time. The Strategy is a bind-once pattern, whereas State is more dynamic. The difference between State and Strategy is in the intent. With Strategy, the choice of algorithm is fairly stable. With State, a change in the state of the "context" object causes it to select from its "palette" of Strategy objects. Context contains state as instance variable and there can be multiple tasks whose implementation can be dependent on the state whereas in strategy pattern strategy is passed as argument to the method and context object doesn’t have any variable to store it.

不同之处在于它们解决的问题不同:

State模式处理对象(处于)什么(状态或类型)——它封装了依赖状态的行为，而 策略模式处理对象如何执行特定任务——它封装了一个算法。

然而，实现这些不同目标的结构非常相似;这两种模式都是带有委托的组合示例。

---

关于它们的优点:

通过使用State模式，状态保持(上下文)类不再知道它是什么状态或类型以及可用的状态或类型。这意味着类遵循开闭设计原则(OCP):类对状态/类型的更改是关闭的，但是状态/类型对扩展是开放的。

By using the Strategy pattern the algorithm-using (context) class is relieved from knowledge of how to perform a certain task (-- the "algorithm"). This case also creates an adherence to the OCP; the class is closed for changes regarding how to perform this task, but the design is very open to additions of other algorithms for solving this task. This likely also improves the context class' adherence to the single responsibility principle (SRP). Further the algorithm becomes easily available for reuse by other classes.

状态在状态派生类中有一点依赖关系:就像一个状态知道接下来的其他状态。例如，对于任何季节状态，夏天在冬天之后，或者对于购物，交付状态在存款状态之后。

另一方面，策略没有这样的依赖关系。在这里，任何类型的状态都可以基于程序/产品类型进行初始化。

有人能用外行的话解释一下吗?

设计模式并不是真正的“门外汉”概念，但我将尽量使其清楚。任何设计模式都可以从三个维度来考虑:

模式解决的问题; 模式的静态结构(类图); 模式的动态(序列图)。

让我们比较国家和战略。

模式解决的问题

State有两种用法[GoF book p. 306]:

An object's behavior depends on its state, and it must change its behavior at run-time depending on that state. Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.

如果您希望确保您确实存在状态模式解决的问题，那么您应该能够使用有限状态机对对象的状态进行建模。你可以在这里找到一个应用的例子。

每个状态转换都是state接口中的一个方法。这意味着对于设计来说，在应用此模式之前必须非常确定状态转换。否则，如果您添加或删除转换，则需要更改接口和实现它的所有类。

我个人认为这种模式并不有用。您总是可以使用查找表实现有限状态机(这不是面向对象的方法，但它工作得非常好)。

策略用于以下[GoF书第316页]:

many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors. you need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms [HO87]. an algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures. a class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class.

在哪里应用Strategy的最后一种情况与称为用多态性替换条件的重构有关。

总结:国家和战略解决的问题完全不同。如果您的问题不能用有限状态机建模，那么可能的状态模式就不合适。如果您的问题不是关于封装复杂算法的变体，那么Strategy就不适用。

模式的静态结构

State具有以下UML类结构:

Strategy具有以下UML类结构:

总结:就静态结构而言，这两种模式基本相同。事实上，像这样的模式检测工具认为“的结构 […]模式是相同的，禁止他们 通过自动过程进行区分(例如，不引用 到概念信息)。”

但是，如果ConcreteStates自己决定状态转换(参见上图中的“可能决定”关联)，那么就会有很大的不同。这导致了具体状态之间的耦合。例如(请参阅下一节)，状态A决定到状态b的转换。如果Context类决定到下一个具体状态的转换，这些依赖关系就消失了。

模式的动态性

正如上面的Problem部分所提到的，State意味着行为在运行时根据对象的某些状态而改变。因此，状态转换的概念适用于有限状态机的关系。[GoF]提到转换可以定义在ConcreteState子类中，也可以定义在一个集中的位置(比如基于表的位置)。

让我们假设一个简单的有限状态机:

假设子类决定状态转换(通过返回下一个状态对象)，动态看起来像这样:

为了展示《战略》的动态，我们可以借用一个真实的例子。

Summary: Each pattern uses a polymorphic call to do something depending on the context. In the State pattern, the polymorphic call (transition) often causes a change in the next state. In the Strategy pattern, the polymorphic call does not typically change the context (e.g., paying by credit card once doesn't imply you'll pay by PayPal the next time). Again, the State pattern's dynamics are determined by its corresponding fininte state machine, which (to me) is essential to correct application of this pattern.

在我看来，主要的区别在于他们的意图。从技术上讲，国家和战略模式看起来非常相似。 主要区别在于:

State模式在需要时更改上下文的状态，并且状态可以多次更改。context改变它的状态或者状态可以设置另一个状态 战略模式决定战略，战略很少会改变，而环境不会改变战略。

策略模式。

我们抽象出一些合理的策略:

public interface ISound
{
    void Make();
}   
    

及其具体策略:

public class DogSoundStrategy : ISound
{
    public void Make()
    {
        Console.WriteLine("Bar");
    }
}

public class CatSoundStrategy : ISound
{
    public void Make()
    {
        Console.WriteLine("Meow");
    }
}

这是对能发声的Animal的抽象描述:

public abstract class Animal
{
    public void MakeSound(ISound sound)
    {
        sound.Make();
    }
}

具体的动物是这样的:

public class Dog : Animal
{
}

public class Cat : Animal
{   
}

然后我们可以像这样调用上面的代码:

Dog dog = new Dog();
dog.MakeSound(new DogSoundStrategy()); // there is a small chance 
    // that you want to change your strategy

Cat cat = new Cat();
cat.MakeSound(new CatSoundStrategy()); // there is a small chance 
    // that you want to change your strategy

有一个小的机会，你想要改变你的策略。

状态模式

想象一下，你有一个电脑游戏，英雄可以是世界上任何一个超级人物。让我们称他为英雄。他能跑、能游、能飞，还能变成钢铁侠或蜘蛛侠。你有一个按钮，你可以改变它的形状或状态为钢铁侠或蜘蛛侠。

英雄的代码是这样的:

public class Hero
{
    IState _state;

    public Hero()
    {
        _state = new SpiderManState();
    }

    public void Run()
    {
        _state.Run();
    }

    public void Swim()
    {
        _state.Swim();
    }

    public void Fly()
    {
        _state.Fly();
    }

    public void ChangeShape()
    {
        _state = _state.SetShape();
    }
}

IState的接口看起来像这样:

public interface IState
{
    void Run();

    void Swim();

    void Fly();

    IState SetShape();
}

具体的状态是这样的:

public class SpiderManState : IState
{
    public void Fly()
    {
        Console.WriteLine("Spiderman is flying");
    }

    public void Run()
    {
        Console.WriteLine("Spiderman is running");
    }

    public void Swim()
    {
        Console.WriteLine("Spiderman is swimming");
    }

    public IState SetShape()
    {
        return new IronManState();
    }
}

IronManState会是这样的:

public class IronManState : IState
{
    public void Fly()
    {
        Console.WriteLine("IronMan is flying");
    }

    public void Run()
    {
        Console.WriteLine("IronMan is running");
    }

    public void Swim()
    {
        Console.WriteLine("IronMan is swimming");
    }

    public IState SetShape()
    {
        return new SpiderManState();
    }
}

现在通过点击英雄类的ChangeShape()按钮，你将能够改变英雄的状态， 例:从蜘蛛侠到钢铁侠。

因此，上下文状态(英雄)取决于并可以通过其按钮ChangeShape进行更改。这种情况会发生很多次。

您很有可能希望更改上下文的状态。

状态模式也可以被认为是替代类中许多if - else语句的一种选择。

The Strategy pattern is really about having a different implementation that accomplishes (basically) the same thing, so that one implementation can replace the other as the strategy requires. For example, you might have different sorting algorithms in a strategy pattern. The callers to the object does not change based on which strategy is being employed, but regardless of strategy the goal is the same (sort the collection). The State pattern is about doing different things based on the state, while leaving the caller relieved from the burden of accommodating every possible state. So for example you might have a getStatus() method that will return different statuses based on the state of the object, but the caller of the method doesn't have to be coded differently to account for each potential state.