0

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

例如，假设我有一个类来处理 I/O。让我们称之为clsIO。我还有一个表单允许用户更改此类的各种选项/属性，我们称之为frmIO. frmIOGUI 是特定于 的，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. 不是反过来。

4

2 回答 2

1

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

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

如果您想保持简单，不费力，只需在clsIO. 这是您可以选择的设计。这个比较简单，所以如果它是一个小而简单的应用程序，应该就足够了。

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

于 2012-07-04T08:25:32.607 回答
1

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

需要有另一个类将它们放在一起，首先实例化 clsIO，然后通过将 clsIO 实例传递给 frmIO 来实例化 frmIO。这样您就可以将每个类的关注点分开，并将布线细化的责任交给另一个，这样会更干净。

此外，您可以通过从 clsIO 类中提取接口并使用 frmIO 中的接口类型来引用 clsIO 来改进设计。这将帮助您在 2 个类之间实现松散耦合。

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

于 2012-07-04T10:07:05.607 回答