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

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.

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.

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

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

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

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

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

策略模式涉及到将算法的实现从宿主类移到单独的类中。这意味着宿主类不需要提供每个算法本身的实现，这很可能导致不干净的代码。

排序算法通常被用作一个例子，因为它们都做同样的事情(排序)。如果将每个不同的排序算法放入自己的类中，那么客户机可以轻松地选择使用哪种算法，并且模式提供了访问算法的简单方法。

状态模式涉及当对象的状态发生变化时改变对象的行为。这意味着宿主类不需要为它可能处于的所有不同状态提供行为的实现。宿主类通常封装提供给定状态下所需功能的类，并在状态改变时切换到不同的类。

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

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

In Strategy pattern while implementing searching , we can have multiple strategies of searching e.g NaiveStrategy(), KMPStrategy() or RabinKarp() Strategy. These are all independent and there are somewhat stable choices. And most important, strategies can't shift from one another. Only Context is able to change strategies. State Pattern on the other hand is based on concept of Finite-State Machines. The states can transition from one another. Here states are less stable as compared to the strategies. And one thing, each concrete state maintains a reference to context and hence is able to transition to another state.

因此，关键在于在策略中，只有上下文可以设置策略，而在状态模式下，状态可以转换到其他状态。在策略模式中，策略彼此不知道。而在状态模式中，状态并不是不知道彼此，并且在它们维护对上下文对象的引用时允许转换。

“策略使这些对象完全独立，彼此不知道。然而，State不限制具体状态之间的依赖关系，允许它们随意改变上下文的状态。”

参考资料:https://refactoring.guru/design-patterns/strategy