Question

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

这里的哲学问题。当我编写Windows窗体应用程序时，我会非常努力地保持UI和数据结构的分离。但是我想知道我是否以最好的方式做到这一点，OO-wise。

例如，如果我有MyClass，并且我的应用程序需要许多，可能存储在List中，我应该将该List作为Form1的成员（Form1是“主”形式）吗？如果没有，我应该在哪里实例化列表？关于公共声明和私人声明的任何意见，还是仅仅是需要什么？

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

  public Form1 ()
  {
    InitializeComponent();
  }
}

Answer 1

这取决于。如果你的列表存储了与UI相关的东西，比如表单控件，那么是的，这可能是它的最佳位置。

否则，它将取决于上下文 - 我们无法在此处看到。

编辑：在某些时候，您的表单必须包含对您的某个非UI类的实例的引用。我认为（尽管如此，没有更多的背景，可以100％确定）这些对象中的一个应该是保持列表的对象。

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

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

Answer 2

所有关于选择数据的范围以及您将定期对它们执行哪些操作。例如，您可能希望程序的其他部分知道该列表，但他们可能知道Form1甚至存在。当你开始以一种实际上并不涉及Form1类的方式对该列表执行操作时，事情也会变得混乱。

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

问问自己这些类型的问题可以为您节省时间，使您的程序更易读，更易于维护。

Answer 3

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

C＃我的数据对象集合应该在哪里实例化？

3 个答案: