6

如果我有一个带有组件/对象（例如我需要从父窗体或其他窗体访问的文本框）的 .Net 窗体，我显然需要将此组件的修饰符“升级”为内部或公共级别的变量。

现在，如果我在我的表单类中提供一个 int 或 string 类型等的公共变量，我不会三思而后行地使用 Getters 和（也许）Setters，即使他们没有做任何事情，只是提供直接访问变量。

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

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

4

4 回答 4

5

"然而，VS 设计者似乎并没有为那些作为表单组件的公共对象实现这样的 Getter/Setter（因此不符合良好的编程习惯）。 "

如果您指的是拖放到表单上的控件，这些控件将被标记为私有实例成员并添加到表单的 Controls 集合中。他们为什么会这样？一个表单可以有四十或五十个控件，为表单上的每个控件提供一个 getter/setter 有点不必要和笨拙。设计者让您通过公共 getter/setter 提供对特定控件的委托访问。

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

于 2008-08-08T14:50:30.130 回答
2

我认为没有为表单上的组件实现 Getter 和 Setter 的原因是因为它们不是“线程安全的”.NET 对象假设只能由创建它们的表单线程修改，如果你使用 getter 和 setter您可能会为任何线程打开它。相反，您假设实现一个委托系统，其中对这些对象的更改被委托给创建它们并在那里运行的线程。

于 2008-08-08T14:42:13.233 回答
2

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

Form 是一个对象，其职责是向用户呈现 UI 并接受输入。Form对象与其他代码区域之间的接口应该是面向数据的接口，而不是暴露Form内部实现细节的接口。表单的内部工作（即控件）应该对任何消费代码保持隐藏。

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

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

这甚至没有提到元开发之类的东西，比如单元测试。

于 2008-08-08T15:51:49.770 回答
1

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

我不明白您所说的“不符合良好的编程习惯”是什么意思。Microsoft 违反了许多良好的编程实践，以便更容易在 Visual Studio 上创建东西（为了快速应用程序开发），我不认为缺少用于控件的 getter/setter 作为违反任何此类最佳实践的证据。

于 2008-08-08T14:41:48.697 回答