在我不断寻求掌握各种设计模式的过程中，我遇到了“状态”设计模式。
首先，让我解释一下我试图在哪里使用这种模式。我有一个表格，我想申请状态。我的程序具有三种状态：Configuration、Processing 和 ProcessingComplete。当表单更改状态时，表单的各个组件将变为启用/禁用、可见/不可见等。
根据我对状态模式的理解，所有这些更改（使组件可见/不可见、启用/禁用等）都应该发生在包含表单实例的单独类中。如果各个State 类与Form 的类分开，State 类就不能访问Form 的组件。我觉得这让我有两种选择之一：
我觉得选项（1）是不好的形式，但我觉得选项（2）在某种程度上违反了状态模式的精神。我的另一个想法是使用选项（2）但使用部分类实现，但是我仍然觉得它违反了状态模式的精神。
我对这两种选择的感受是不公平的，还是我什至没有想到其他选择？
I would avoid partial implementations. Usually hey don't give any added value, and make the code harder to read. The only place I can think of where partial classes are a good idea is when part of your code is auto-generated (like in the WinForms designer).
What about using MVP or some kind of binding? If you bind the Visible and Enabled properties of your controls to a Model class, then you can hold an instance of that Model instead of holding an instance of a form.
我会选择选项 2。“状态”仅用于“表单”，因此它在语义上是固有的，那么为什么不在类层次结构中使用它呢？
你错过了第三种选择。
包括国家将控制的部分作为班级合同的一部分。
因此，如果您的目标是修改标签的文本，则您的基本 State 类应该要求向其发送标签。然后，您可以在表单上设置适当的字段的InitializeState(State myState)or方法。BuildStates()
选项1是错误的。当你设计你的状态时，选项 2 真的变得不必要了，它只能按照给定的方式行动，这实际上是对象应该如何行动。