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

来自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.

“策略”只是一种算法，你可以根据自己的需要在不同的情况下改变它，它为你处理一些事情。 例如，你可以选择如何压缩一个文件。Zip or rar…在一个方法中。

但是“状态”可以改变你所有的对象行为，当它改变时， 甚至它也能改变其他领域……这就是为什么它有一个指向它的主人的引用。您应该注意到，改变对象字段完全可以改变对象行为。 例如，当你在obj中将stat0更改为State1时，你将一个整数更改为10。因此，当我们调用obj.f0()进行一些计算并使用该整数时，它会影响结果。

老实说，这两种模式在实践中非常相似，它们之间的定义差异往往取决于你问谁。一些流行的选择是:

状态存储对包含它们的上下文对象的引用。战略则不然。 状态可以替换自己(IE:将上下文对象的状态更改为其他状态)，而策略则不能。 策略作为参数传递给上下文对象，而状态由上下文对象本身创建。 策略只处理一个特定的任务，而状态为上下文对象所做的所有(或几乎所有)事情提供底层实现。

一个“经典”的实现将匹配列表中的每个道具的状态或策略，但你也会遇到混合了两者的情况。具体是国家层面的还是战略层面的，最终是一个主观问题。

策略:策略是固定的，通常由几个步骤组成。(排序只构成了一个步骤，因此是一个非常糟糕的例子，因为它太原始了，无法理解此模式的目的)。 策略中的“主”例程调用了一些抽象方法。如。“进入房间策略”，“main-method”是goThroughDoor()，它看起来像:approachDoor()， if (locked()) openLock();openDoor ();enterRoom ();把();closeDoor ();if (wasLocked()) lockDoor();

现在，这个通用“算法”的子类可以实现该算法的步骤，该算法用于通过可能锁着的门从一个房间移动到另一个房间。

换句话说，策略子类化不会改变基本算法，只会改变单个步骤。

上面是一个模板方法模式。现在把属于一起的步骤(解锁/锁定和打开/关闭)放到它们自己的实现对象中，并委托给它们。例如，带钥匙的锁和带码卡的锁是两种锁。将策略委托给“Step”对象。现在您有了一个策略模式。

状态模式是完全不同的东西。

你有一个包装对象和被包装的对象。被包装的是“状态”。状态对象只能通过它的包装器访问。现在您可以随时更改包装对象，因此包装器似乎可以更改其状态，甚至更改其“类”或类型。

E.g. you have a log on service. It accepts a username and a password. It only has one method: logon(String userName, String passwdHash). Instead of deciding for itself whether a log on is accepted or not, it delegates the decision to a state object. That state object usually just checks if the user/pass combination is valid and performs a log on. But now you can exchange the "Checker" by one that only lets priviledged users log on (during maintanace time e.g.) or by one that lets no one log on. That means the "checker" expresses the "log on status" of the system.

最重要的区别是:当你选择了一种策略，你要坚持它，直到你完成它。这意味着你调用它的“主方法”，只要它在运行，你就永远不会改变策略。OTOH在系统运行时的状态模式情况下，您可以随意更改您认为合适的状态。

战略模式和状态模式具有相同的结构。如果您查看两种模式的UML类图，它们看起来完全相同，但是它们的意图完全不同。状态设计模式用于定义和管理对象的状态，而策略模式用于定义一组可互换的算法，并让客户选择其中之一。因此，策略模式是客户端驱动的模式，而对象可以管理自己的状态。

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

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语句的一种选择。