如果我的.Net表单带有需要从父级或者其他表单访问的组件/对象(例如文本框)，则显然需要将该组件的修饰符"升级"到内部或者公共级别的变量。

现在，如果我在表单类中提供了一个int或者字符串类型等公共变量，那么我不会再三考虑使用Getter和(也许)Setter来解决这个问题，即使他们除了提供直接命令外也没有做其他事情访问变量。

但是，VS设计器似乎并未为作为表单上组件的那些公共对象实现此类Getter / Setter(因此不符合良好的编程习惯)。

所以，问题是；为了做"正确的事情"，我应该将此类VS设计器组件或者对象包装在Getter和/或者Setter中吗？

解决方案

回答

我总是这样做，如果我们遵循MVP设计，则为视图组件创建getter / setter方法将是设计要求。

我不理解意思是"不遵守良好的编程习惯"。 Microsoft违反了许多良好的编程习惯，以使其更容易在Visual Studio上创建内容(为了快速开发应用程序)，并且我不认为缺少控件的getter / setter方法可以作为违反任何此类最佳实践的证据。

回答

我认为无法在表单上为组件实现Getters和Setters的原因是，它们不会是"线程安全的"。.NET对象应该仅由创建它们的表单线程修改，如果我们穿上getter和setters我们可能会为任何线程打开它。相反，我们应该实现一个委托系统，其中将对这些对象的更改委托给创建它们并在其中运行的线程。

回答

"但是，VS设计器似乎并未为作为表单上组件的那些公共对象实现此类Getter / Setters(因此不符合良好的编程习惯)。"

如果我们是指要拖放到窗体上的控件，则这些控件将被标记为私有实例成员，并被添加到窗体的Controls集合中。为什么会这样呢？一个表单可以有40个或者50个控件，为表单上的每个控件提供一个getter / setter方法在某种程度上是不必要的和笨拙的。设计人员将其留给我们，以通过公共获取者/设置者提供对特定控件的委托访问。

设计师在这里做正确的事。

回答

这是面向对象设计中封装的经典示例。

表单是一个对象，其职责是向用户显示UI并接受输入。 Form对象和代码其他区域之间的接口应该是面向数据的接口，而不是公开Form的内部实现细节的接口。窗体的内部工作原理(即控件)应在任何使用代码中保持隐藏。

一个成熟的解决方案可能涉及以下设计要点：

• 公共方法或者属性是行为(显示，隐藏，定位)或者面向数据的(设置数据，获取数据，更新数据)。
• 由Form实现的所有事件处理程序都包装在适当的线程委托代码中，以强制执行Form线程执行规则。
• 控件本身将与底层数据结构进行数据绑定(以适当的方式)以减少代码。

而且这甚至都没有提到诸如单元测试之类的元开发。