如果我有一个带有组件/对象（例如我需要从父窗体或其他窗体访问的文本框）的 .Net 窗体，我显然需要将此组件的修饰符“升级”为内部或公共级别的变量。
现在，如果我在我的表单类中提供一个 int 或字符串类型等的公共变量，我不会三思而后行地使用 Getters 和（也许）Setters，即使他们没有做任何其他事情而不是提供对变量的直接访问。
但是，VS 设计器似乎没有为那些作为表单组件的公共对象实现此类 Getter/Setter（因此不符合良好的编程习惯）。
所以，问题是；为了做“正确的事”，我应该将此类 VS 设计器组件或对象包装在 Getter 和/或 Setter 中吗？
【问题讨论】：
"然而，VS 设计者似乎并没有为那些作为表单组件的公共对象实现这样的 Getter/Setter（因此不符合良好的编程习惯）。"
如果您指的是拖放到表单上的控件，这些控件将被标记为私有实例成员并添加到表单的 Controls 集合中。他们为什么会这样？一个表单可以有四十或五十个控件，为表单上的每个控件提供一个 getter/setter 有点不必要和笨拙。设计师让您通过公共 getter/setter 提供对特定控件的委派访问。
设计师在这里做了正确的事。
【讨论】：
这是面向对象设计中封装的经典例子。
Form 是一个对象，其职责是向用户呈现 UI 并接受输入。 Form对象与其他代码区域的接口应该是面向数据的接口，而不是暴露Form内部实现细节的接口。表单的内部工作原理（即控件）应该对任何消费代码保持隐藏。
一个成熟的解决方案可能会涉及以下设计要点：
这甚至没有提到元开发的东西，比如单元测试。
【讨论】：
我认为没有为表单上的组件实现 Getter 和 Setter 的原因是因为它们不是“线程安全的”.NET 对象假设只能由创建它们的表单线程修改，如果你穿上getter 和 setter 你可能会为任何线程打开它。相反，您假设实现一个委托系统，其中对这些对象的更改被委托给创建它们并在那里运行的线程。
【讨论】：
我总是这样做，如果您遵循 MVP 设计，为您的视图组件创建 getter/setter 将是设计要求。
我不明白您所说的“不符合良好的编程习惯”是什么意思。 Microsoft 违反了很多良好的编程实践，以便更容易在 Visual Studio 上创建东西（为了快速应用程序开发），我不认为缺少用于控件的 getter/setter 作为证据违反任何此类最佳做法。
【讨论】：