3

我正在使用 C#，但我认为这适用于大多数编程语言。

哲学问题在这里。当我编写 Windows 窗体应用程序时，我非常努力地将 UI 和数据结构分开。但我想知道我是否以最好的方式做这件事，面向对象。

例如，如果我有 MyClass，并且我的应用程序需要其中的许多，也许存储在一个列表中，我应该使该列表成为 Form1 的成员（Form1 是“主”表单）吗？如果没有，我应该在哪里实例化列表？关于公共声明与私人声明的任何意见，还是只是需要什么？

public partial class Form1 : Form 
{
  private List<MyClass> myClassList; // good idea? Bad idea?

  public Form1 ()
  {
    InitializeComponent();
  }
}
4

3 回答 3

3

这取决于。如果您的列表存储与 UI 相关的内容，例如表单控件，那么是的，这可能是它的最佳位置。

否则，这将取决于上下文 - 我们在这里看不到全部内容。

编辑：在某些时候，您的表单必须包含对您的非 UI 类之一的实例的引用。我认为（尽管再次，没有更多上下文，不能 100% 确定）这些对象之一应该是保留列表的对象。

尽量让你的逻辑独立于表单——即：尽可能少地从表单中操作该列表，并且尽可能多地从非 UI 类中操作。您最终可能会发现，您根本不需要表单来保存对列表的引用。

再次编辑：如果我有一个宠物店系统，我可能有一个Kennel类和一个包含Pup类项目的通用列表。kennel 实例将保存小狗列表，而不是 UI。我希望这个小例子能更清楚地说明我的观点。

于 2013-08-19T18:33:11.827 回答
1

这完全是关于选择数据的范围以及您将定期对它们执行什么样的操作。例如，您可能希望程序的其他部分知道该列表，但他们可能不必知道该列表是否存在Form1。当您开始以与类无关的方式对该列表执行操作时，事情也会变得混乱Form1。

每当你创建一个新变量时，问自己一些问题。其他类需要知道这个变量吗？我是否需要对这个变量执行独立于表单的操作？这个变量真的属于表格吗？

问自己这些类型的问题可以节省您将来的时间，并使您的程序更具可读性和更易于维护。

于 2013-08-19T18:36:58.633 回答
0

对象列表的内部表示还不错（尽管如果您只需要它来绘制表单，您应该有充分的理由浪费额外的内存），但是列表（如果需要有意义地呈现表单）应该是构造函数中的参数。

于 2013-08-19T18:30:51.697 回答