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

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

这是一个相当老的问题，但我也在寻找同样的答案，这就是我所发现的。

对于状态模式，让我们考虑一个中间播放器播放按钮的例子。当我们开始播放时，它开始播放，并让上下文意识到它正在播放。每次客户端想要执行播放操作时，他都会检查播放器的当前状态。现在客户端知道对象的状态是通过上下文对象播放的，所以他调用暂停状态对象的动作方法。客户端实现状态的部分以及它需要在什么状态上执行操作的部分可以被自动化。

https://www.youtube.com/watch?v=e45RMc76884 https://www.tutorialspoint.com/design_pattern/state_pattern.htm

在策略模式的情况下，类图的安排与状态模式相同。客户来此安排做一些操作。也就是说，不同的算法取代了不同的状态，比如需要对模式进行不同的分析。在这里，客户端告诉上下文它想做什么，用什么算法(业务定义的自定义算法)，然后执行。

https://www.tutorialspoint.com/design_pattern/strategy_pattern.htm

两者都实现了开闭原则，因此开发人员可以向状态模式和新算法中添加新的状态。

但不同之处在于它们使用的是基于对象状态执行不同逻辑的状态模式。在战略的案例中有不同的逻辑。

策略表示“做”某事的对象，具有相同的开始和结束结果，但内部使用不同的方法。在这个意义上，它们类似于表示动词的实现。状态模式OTOH使用的对象“是”某种东西——操作的状态。虽然它们也可以表示对该数据的操作，但它们更类似于名词的表示，而不是动词的表示，并且是为状态机定制的。

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

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

当你有一个可以分为两个任务的项目时:

任务1:您可以使用两种不同的算法之一来完成:alg1, alg2

任务2:您可以使用三种不同的算法之一来完成:alg3, alg4, alg5

Alg1和alg2是可互换的;Alg3、alg4和alg5是可以互换的。

在任务1和任务2中选择哪种算法取决于状态:

状态1:任务1中需要alg1，任务2中需要alg3

状态2:任务1中需要alg2，任务2中需要alg5

上下文可以将状态对象从状态1更改为状态2。然后，您的任务将由alg2和alg5完成，而不是alg1和alg3。

您可以为任务1或任务2添加更多可互换的算法。这就是战略模式。

你可以在任务1和任务2中使用不同的算法组合获得更多的状态。状态模式允许从一种状态切换到另一种状态，并执行不同的算法组合。

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

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