状态模式：我应该信任哪个类来更新状态？

Question

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

在本书中，具有状态的类称为Context，而实际状态实现 State接口。当给出请求时，书籍使用此处的方法来改变状态：

1. Context接收请求;
2. Context调用它所拥有的State上的handle（）方法，将请求交给State;
3. 状态处理请求，并在上下文中设置状态是否应该更改。为此，各州将“上下文”作为一个字段。

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

1. Context接收请求;
2. Context调用它所拥有的State上的handle（）方法，将请求交给State;
3. 国家处理请求，并返回一个州;是否是另一个国家取决于请求的处理方式。
4. Context将自己的State设置为返回的状态。

我能想到的优点和缺点：

1. 如果我们把所有可以变化的东西都变成国家级，那么Context和State会变得更加分离，因为他们不需要窥视彼此的领域;
2. 州级可能会变得更大;
3. 国家可能不容易在不同的背景中重复使用。但是，我们可以将States实现为实现State接口的抽象类，并使Contexts使用的具体状态继承抽象状态。

是否有任何特定原因，第一个（由 Head First Design Patterns 使用）应该受到青睐，或者第二个选择在实践中也有效并且可能有一些我没看到的严重缺陷？

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

Answer 1

您提到的方法的问题是，任何其他引用State对象的对象都无法在您描述的场景中获得更新。正如你所描述的那样，国家可以归还另一个拥有最新国家的国家，而且上下文可以取代其对具有更新国家的国家的提及，但是任何其他提到国家的对象现在都有一个悬而未决的国家。由Context提到。

Answer 2

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