design-patterns - 状态模式 : Which class should I trust to update the state?

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

5年前关闭。




Improve this question




我正在通过阅读 Head First Design Patterns 来学习设计模式，并且我刚刚完成了关于状态模式的章节。但是，有一件事我没有得到:

在书中，有状态的类称为Context，而实际的状态实现State接口(interface)。当给书一个请求时，使用这里的方法来改变状态:

Context接收请求；

Context 在它拥有的 State 上调用 handle() 方法，将请求交给 State；

State 处理请求，并在 Context 中设置 State 如果它应该改变。为此，States 将 Context 作为一个字段。

但是，在我看来，这似乎在两个类之间给出了某种“递归”耦合，并且是不直观的。如果我没有阅读他们的解决方案，我更喜欢以下设计:

Context接收请求；

Context 在它拥有的 State 上调用 handle() 方法，将请求交给 State；

State 处理请求，并返回一个 State；是否是另一个国家取决于如何处理请求。

上下文将自己的状态设置为返回的状态。

我能想到的优点和缺点:

如果我们将所有可能变化的东西放入 State 类、Context 和 State 中，并变得更加解耦，因为它们不需要窥视彼此的字段；

State 类可能会变得更大；

状态可能不容易在不同的上下文中重用。但是，我们可以将状态实现为实现状态接口(interface)的抽象类，并具有由抽象状态子类化的上下文使用的具体状态。

是否有任何具体原因应该支持第一个(Head First Design Patterns 使用的)，或者第二个选择也有效并在实践中使用，或者它有一些我没有看到的严重缺陷？

感谢您的所有投入以及您花时间阅读和回复!

Answer 1

您提到的方法的问题是，引用 State 对象的任何其他对象都无法在您描述的场景中获得更新。正如您所描述的，State 可以返回另一个具有更新 State 的 State，并且 Context 可以用更新的 State 替换其对 State 的引用，但是任何其他引用 State 的对象现在都将有一个悬空引用，而不是上下文所指。