2

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

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

  1. Context接收请求；
  2. Context 在它拥有的 State 上调用 handle() 方法，将请求交给 State；
  3. State 处理请求，并在 Context 中设置 State 如果它应该改变。为此，States 将 Context 作为一个字段。

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

  1. Context接收请求；
  2. Context 在它拥有的 State 上调用 handle() 方法，将请求交给 State；
  3. State 处理请求，并返回一个 State；是否是另一个国家取决于如何处理请求。
  4. 上下文将自己的状态设置为返回的状态。

我能想到的优点和缺点：

  1. 如果我们将所有可能变化的东西放入 State 类、Context 和 State 中并变得更加解耦，因为它们不需要窥视彼此的字段；
  2. State 类可能会变得更大；
  3. 状态可能不容易在不同的上下文中重用。但是，我们可以将States 实现为实现State 接口的抽象类，并具有由抽象States 子类化的Contexts 使用的具体States。

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

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

4

2 回答 2

2

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

于 2011-08-02T18:22:22.377 回答
1

还有第三种方法，不是将上下文作为状态的成员，而是将状态实现为单例模式，并将上下文作为参数传递给状态的事件成员函数。这与享元模式中使用的技术相同。这样，可以使用一组上下文，但每个状态只能使用一个实例。

于 2011-08-03T17:19:06.050 回答