战略设计模式和国家设计模式之间的区别是什么?我在网上浏览了不少文章，但看不出明显的区别。
有人能用外行的语言解释一下吗?
当前回答
有人能用外行的话解释一下吗?
设计模式并不是真正的“门外汉”概念，但我将尽量使其清楚。任何设计模式都可以从三个维度来考虑:
模式解决的问题; 模式的静态结构(类图); 模式的动态(序列图)。
让我们比较国家和战略。
模式解决的问题
State有两种用法[GoF book p. 306]:
An object's behavior depends on its state, and it must change its behavior at run-time depending on that state. Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.
如果您希望确保您确实存在状态模式解决的问题，那么您应该能够使用有限状态机对对象的状态进行建模。你可以在这里找到一个应用的例子。
每个状态转换都是state接口中的一个方法。这意味着对于设计来说，在应用此模式之前必须非常确定状态转换。否则，如果您添加或删除转换，则需要更改接口和实现它的所有类。
我个人认为这种模式并不有用。您总是可以使用查找表实现有限状态机(这不是面向对象的方法，但它工作得非常好)。
策略用于以下[GoF书第316页]:
many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors. you need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms [HO87]. an algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures. a class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class.
在哪里应用Strategy的最后一种情况与称为用多态性替换条件的重构有关。
总结:国家和战略解决的问题完全不同。如果您的问题不能用有限状态机建模，那么可能的状态模式就不合适。如果您的问题不是关于封装复杂算法的变体，那么Strategy就不适用。
模式的静态结构
State具有以下UML类结构:
Strategy具有以下UML类结构:
总结:就静态结构而言，这两种模式基本相同。事实上，像这样的模式检测工具认为“的结构 […]模式是相同的，禁止他们 通过自动过程进行区分(例如，不引用 到概念信息)。”
但是，如果ConcreteStates自己决定状态转换(参见上图中的“可能决定”关联)，那么就会有很大的不同。这导致了具体状态之间的耦合。例如(请参阅下一节)，状态A决定到状态b的转换。如果Context类决定到下一个具体状态的转换，这些依赖关系就消失了。
模式的动态性
正如上面的Problem部分所提到的，State意味着行为在运行时根据对象的某些状态而改变。因此，状态转换的概念适用于有限状态机的关系。[GoF]提到转换可以定义在ConcreteState子类中，也可以定义在一个集中的位置(比如基于表的位置)。
让我们假设一个简单的有限状态机:
假设子类决定状态转换(通过返回下一个状态对象)，动态看起来像这样:
为了展示《战略》的动态，我们可以借用一个真实的例子。
Summary: Each pattern uses a polymorphic call to do something depending on the context. In the State pattern, the polymorphic call (transition) often causes a change in the next state. In the Strategy pattern, the polymorphic call does not typically change the context (e.g., paying by credit card once doesn't imply you'll pay by PayPal the next time). Again, the State pattern's dynamics are determined by its corresponding fininte state machine, which (to me) is essential to correct application of this pattern.
其他回答
状态在状态派生类中有一点依赖关系:就像一个状态知道接下来的其他状态。例如，对于任何季节状态，夏天在冬天之后，或者对于购物，交付状态在存款状态之后。
另一方面，策略没有这样的依赖关系。在这里，任何类型的状态都可以基于程序/产品类型进行初始化。
有人能用外行的话解释一下吗?
设计模式并不是真正的“门外汉”概念，但我将尽量使其清楚。任何设计模式都可以从三个维度来考虑:
模式解决的问题; 模式的静态结构(类图); 模式的动态(序列图)。
让我们比较国家和战略。
模式解决的问题
State有两种用法[GoF book p. 306]:
An object's behavior depends on its state, and it must change its behavior at run-time depending on that state. Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.
如果您希望确保您确实存在状态模式解决的问题，那么您应该能够使用有限状态机对对象的状态进行建模。你可以在这里找到一个应用的例子。
每个状态转换都是state接口中的一个方法。这意味着对于设计来说，在应用此模式之前必须非常确定状态转换。否则，如果您添加或删除转换，则需要更改接口和实现它的所有类。
我个人认为这种模式并不有用。您总是可以使用查找表实现有限状态机(这不是面向对象的方法，但它工作得非常好)。
策略用于以下[GoF书第316页]:
many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors. you need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms [HO87]. an algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures. a class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class.
在哪里应用Strategy的最后一种情况与称为用多态性替换条件的重构有关。
总结:国家和战略解决的问题完全不同。如果您的问题不能用有限状态机建模，那么可能的状态模式就不合适。如果您的问题不是关于封装复杂算法的变体，那么Strategy就不适用。
模式的静态结构
State具有以下UML类结构:
Strategy具有以下UML类结构:
总结:就静态结构而言，这两种模式基本相同。事实上，像这样的模式检测工具认为“的结构 […]模式是相同的，禁止他们 通过自动过程进行区分(例如，不引用 到概念信息)。”
但是，如果ConcreteStates自己决定状态转换(参见上图中的“可能决定”关联)，那么就会有很大的不同。这导致了具体状态之间的耦合。例如(请参阅下一节)，状态A决定到状态b的转换。如果Context类决定到下一个具体状态的转换，这些依赖关系就消失了。
模式的动态性
正如上面的Problem部分所提到的，State意味着行为在运行时根据对象的某些状态而改变。因此，状态转换的概念适用于有限状态机的关系。[GoF]提到转换可以定义在ConcreteState子类中，也可以定义在一个集中的位置(比如基于表的位置)。
让我们假设一个简单的有限状态机:
假设子类决定状态转换(通过返回下一个状态对象)，动态看起来像这样:
为了展示《战略》的动态，我们可以借用一个真实的例子。
Summary: Each pattern uses a polymorphic call to do something depending on the context. In the State pattern, the polymorphic call (transition) often causes a change in the next state. In the Strategy pattern, the polymorphic call does not typically change the context (e.g., paying by credit card once doesn't imply you'll pay by PayPal the next time). Again, the State pattern's dynamics are determined by its corresponding fininte state machine, which (to me) is essential to correct application of this pattern.
考虑一个处理客户呼叫的IVR(交互式语音应答)系统。你可能想要编程它来处理客户:
工作日 假期
要处理这种情况，您可以使用状态模式。
节假日:IVR简单地回复说“只能在工作日上午9点到下午5点之间接听电话”。 工作日:它通过将客户连接到客户服务主管来响应。
这个连接客户和支持高管的过程本身可以使用一个策略模式来实现，其中高管是根据以下任何一个来挑选的:
轮循 最近最少使用 其他基于优先级的算法
策略模式决定“如何”执行某些操作，状态模式决定“何时”执行这些操作。
这两种模式都用于改变对象的行为，
按照设计，状态模式对象只有一个状态，对象的行为基于实现的单个状态(类)及其子类。
相反，策略没有单一的状态，对象的行为是由不同策略对象的实现决定的。
策略模式涉及到将算法的实现从宿主类移到单独的类中。这意味着宿主类不需要提供每个算法本身的实现，这很可能导致不干净的代码。
排序算法通常被用作一个例子，因为它们都做同样的事情(排序)。如果将每个不同的排序算法放入自己的类中，那么客户机可以轻松地选择使用哪种算法，并且模式提供了访问算法的简单方法。
状态模式涉及当对象的状态发生变化时改变对象的行为。这意味着宿主类不需要为它可能处于的所有不同状态提供行为的实现。宿主类通常封装提供给定状态下所需功能的类，并在状态改变时切换到不同的类。
