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

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

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

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

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

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.

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

这两种模式都用于改变对象的行为，

按照设计，状态模式对象只有一个状态，对象的行为基于实现的单个状态(类)及其子类。

相反，策略没有单一的状态，对象的行为是由不同策略对象的实现决定的。

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