Design patterns 我可以得到一些关于国家行为模式的澄清吗？

我正在考虑使用

State

模式将代码中的大型

switch

语句转换为更易于管理的块

我一直在阅读关于它的文章，同时也在看一个教程的例子

该示例中的代码在我看来是错误的，因为作者正在从

上下文

之外调用

状态

功能。对吗

我的理解是，上下文应该是状态的包装器，而

State

更改很可能应该从每个

State

对象中处理。否则就有点违背目的了，对吧

在谷歌上搜索设计模式书时，请在下面的模式图中说明：

我遇到了，这更符合我的想法。 因此，我认为教程点示例不正确，

状态

应该由状态本身更改，或者由保存

上下文

并调用

Context.request（）

的

对象

更改，对吗

---

是否有一个有效的案例可以像教程中的例子那样做？我自己看不出来，如果你这样做，你只会得到另一个

开关
或
if
语句。
是的，你是正确的，上下文只应该访问状态：上下文是状态的唯一客户端

下面是java中状态的一个实现。
在我看来，该示例中的代码是错误的，因为作者是从上下文之外调用状态功能的。对吗？

是的，您是对的，给定的示例很差地说明了状态模式。在这里，它更像是一种策略，因为上下文对象接收新的行为，而不是调整它本身

…状态应该由状态本身更改，或者由通过调用Context.request（）保存上下文的对象更改？

对。State类负责设置上下文的“下一个状态”。可以使用状态模式轻松创建状态机：


上下文是更新当前状态的机器，它保存一些决策信息
每个状态定义执行的操作，并根据上下文测试到其他状态的“转换”。如果发生转换，则上下文的状态将更新为新状态

像教程中的Point示例那样做是否有正当理由？我自己看不出来，如果你那样做，你只会得到另一个开关或if语句。

我认为从外部更新上下文状态有两个原因：


选择上下文的初始状态（可以由构造函数注入）
中断或重置上下文，例如，在嵌入式世界中，接收ISR时通常会出现这种情况