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

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

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

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

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

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:将上下文对象的状态更改为其他状态)，而策略则不能。 策略作为参数传递给上下文对象，而状态由上下文对象本身创建。 策略只处理一个特定的任务，而状态为上下文对象所做的所有(或几乎所有)事情提供底层实现。

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

考虑一个处理客户呼叫的IVR(交互式语音应答)系统。你可能想要编程它来处理客户:

工作日 假期

要处理这种情况，您可以使用状态模式。

节假日:IVR简单地回复说“只能在工作日上午9点到下午5点之间接听电话”。 工作日:它通过将客户连接到客户服务主管来响应。

这个连接客户和支持高管的过程本身可以使用一个策略模式来实现，其中高管是根据以下任何一个来挑选的:

轮循 最近最少使用 其他基于优先级的算法

策略模式决定“如何”执行某些操作，状态模式决定“何时”执行这些操作。