C# 内部类和/或部分类是否脱离了状态设计模式的原则？

在我不断寻求掌握各种设计模式的过程中，我遇到了“状态”设计模式

首先，让我解释一下我在哪里尝试使用这个模式。我有一张我想申请的表格。我的程序有三种状态：配置、处理和处理完成。当表单更改状态时，表单的各个组件将变为启用/禁用、可见/不可见等

根据我对状态模式的理解，所有这些更改（使组件可见/不可见、启用/禁用等）都应该发生在包含表单实例的单独类中。如果各种状态类与窗体的类分开，则状态类无法访问窗体的组件。我觉得这让我有两个选择：

将窗体的组件公开为公共组件

使状态类成为表单的内部类

我觉得选项（1）的形式不好，但我觉得选项（2）在某种程度上违背了状态模式的精神。我的另一个想法是使用选项（2），但是使用部分类实现，但是我仍然觉得这违反了状态模式的精神

---

我对这两种选择的感觉是不公平的，还是有另一种选择我甚至没有想到？

我会避免部分实现。通常情况下，他们不给任何附加值，使代码更难阅读。我能想到的唯一一个地方是，当代码的一部分自动生成时（比如在WinForms设计器中），分部类是一个好主意

---

使用MVP或某种绑定怎么样？如果将控件的可见和已启用属性绑定到模型类，则可以保留该模型的实例，而不是表单的实例。

我选择选项2。“State”仅用于“Form”，因此它在语义上是它固有的，所以为什么不在类层次结构中使用它呢？

您缺少第三个选项

包括国家将控制的部分，作为该类合同的一部分

因此，如果您的目标是修改标签的文本，那么您的基本状态类应该要求向其发送标签。然后，您可以在表单上使用

InitializeState（State myState）

或

BuildStates（）

方法来设置适当的字段

---

选项1是错误的。当你设计你的状态时，选项2真的变得不必要了，因为它只能作用于给定的状态，而这正是对象无论如何应该起作用的方式。

我同意……为什么你不能使用继承呢。这就是OOP的设计目的。首先，我看到部分实现的方式纯粹是帮助将代码的逻辑部分分离到单独的文件中。如果你喜欢的话，可以防止文件变得太大其次，我仍然在思考MVP的各个方面。@Shynthriir这是在处理症状，而不是解决问题。如果您的类太大，以至于您想将其划分为单独的文件，那么您应该将其划分为单独的类。大类是不稳定的。类应该只有一个职责，它们不应该在逻辑上是可分离的。我真的很喜欢这个想法。我没有想到这一点，因为我习惯于让我的类保持相当不变，这意味着我必须实现一个可能相当复杂的构造函数（在本例中，复杂意味着很多参数）。进一步思考：“当您设计状态时，选项2真的变得不必要，因为它只能执行给定的操作。”. 在选项2中，必须给State类一个表单实例。优点是状态可以访问表单实例的私有成员，因为状态类是嵌套的。@ SynRistRi:我真的不认为一个类访问另一个私有成员是一个优势；它是紧密耦合的代码。即使嵌套，它们也应该只访问给定的内容，而不是可以看到的内容。