Question

处理类对象的GUI的最佳方法是什么（读取：技术上最正确的）？

比如说，我有一个类来处理I / O.我们称之为clsIO。我还有一个表单允许用户更改此类的各种选项/属性，我们称之为frmIO。 frmIO GUI特定于clsIO，不会在应用程序的任何其他位置使用。

我的应用程序将始终创建clsIO的实例，它将加载其默认设置并开始其操作。用户可能需要也可能不需要显示frmIO'设置表单'，以便他可以配置它。

对我而言，处理此问题的最佳方法似乎是将对象引用存储在类中的表单中，并提供ShowConfigForm()方法，而不是实例化表单，而表单又实例化了类

这是声音设计吗？

修改

我打算在多个项目中重用这个类/表单组合。我已经在自己的项目中开发了它，因此我可以轻松地转移/导入到可能需要它的其他项目。

使用我当前设计的简单伪代码：

class clsIO
{
  public bool Active{get;set;}
  public int Port{get;set;}
  public ShowConfigForm()
  {
    frmIO settings = new frmIO(this);
    settings.Show();
  }
}

class frmIO
{
  private clsIO _IO;
  public frmIO(clsIO IO){_IO = IO;};//constructor
  private btnEnable_Click()
  {
     _IO.Active = true;
    //etc etc
  }
}

这里我只需要实例化clsIO。不是相反。

Answer 1

通常你会有一个包含配置的类。表单本身引用了settings类。如果用户更改了表单中的设置，则表单会将其告知settings类/对象。

现在，您可以在设置中注册clsIO观察员。意味着无论何时发生变化，clsIO都会得到通知并可以更新其操作（这种方式，设置将包含对其所有观察者的引用）。这被称为observer pattern。如果许多“未知”物体观察到某些东西，它的力量有多我的意思是，设置可能是某些东西，会影响许多不同的类/对象。观察者只决定设置，但从不改变它们。

如果您想保持简单，不费吹灰之力，只需在clsIO中添加对设置的引用即可。这是一个你可以选择的设计。这个更简单，所以如果它是一个小而简单的应用程序，那就足够了。

但我认为你应该做的是将表格与价值分开。表单只是一个视图，而实际值包含在另一个类中。

Answer 2

你做的方式，从clsIO到frmIO（这是GUI类）的紧密耦合。这不是一个好的做法，因为这种紧耦合会阻止你进行单元测试等。如果你需要clsIO重新用于其他一些操作，这种与fromIO的紧密耦合会阻止你这样做。

需要有另一个类将它们放在一起，首先实例化clsIO，然后通过将clsIO实例传递给frmIO来实现frmIO。通过这种方式，您可以将每个类别的问题分开，并将负责连接到另一个类别，这将更加清洁。

此外，您可以通过从clsIO类中提取接口并使用frmIO中的接口类型来引用clsIO来改进设计。这将有助于你在两个班级之间进行松耦合。

如果我提供代码示例，请告诉我，如果我所描述的内容没有多大意义。

OOP - Form持有类实例或类持有表单实例？

2 个答案: