2

在您的 Windows 窗体上创建一个在单击时执行某些操作的按钮。

引发的点击事件通常绑定到一个方法，例如

受保护的无效Button1_Click（对象发送者，EventArgs e）{

}

我有时在其他人的代码中看到的是，按钮行为的实现不是放入 Button1_Click 方法中，而是放入从这里调用的自己的方法中，如下所示：

私人 DoStuff() { }

protected void Button1_Click(object sender, EventArgs e) { this.DoStuff(); }

尽管我在这里看到了优势（例如，如果在其他地方内部需要这段代码，它可以很容易地使用），但我想知道，这是否是一个普遍的良好设计决策？

所以问题是：将事件处理代码放入自己的方法中是否是一个普遍的好主意，如果是这样，这些方法的哪些命名约定被证明是最佳实践？

4

4 回答 4

4

如果出现以下情况，我会将事件处理代码放入单独的方法中：

  • 该代码将由多个事件或从其他任何地方调用，或
  • 代码实际上与 GUI 无关，更像是后端工作。

所有小的和仅与 GUI 相关的东西总是进入处理程序，有时即使它是从同一个事件中调用的（只要签名相同）。所以更像是，如果是通用动作，就使用单独的方法，如果方法与实际事件密切相关，则不要。

于 2008-10-01T11:59:57.993 回答
2

一个好的经验法则是查看该方法是在执行某些特定于 UI 的操作，还是实际执行通用操作。例如，臀部点击方法可以处理点击或提交表单。如果是前一种，可以将其留在 button_click 处理程序中，但后者应该有自己的方法。我要说的是，牢记单一责任原则。

于 2008-10-01T11:58:56.183 回答
1

在这种情况下，我会保留 DoStuff() 方法，但通过以下方式订阅它：

button1.Click += delegate { DoStuff(); }

诚然，这不会取悦那些在设计器中完成所有事件接线的人......但我个人觉得检查起来更简单。（我也讨厌自动生成的事件处理程序名称......）

于 2008-10-01T12:10:33.160 回答
0

直接的答案是肯定的。最好将任务封装到它自己的方法中，不仅是为了在其他地方重用，而且从 OOP 的角度来看，这样做是有意义的。在这种特殊情况下，单击按钮会启动一个进程调用 DoStuff。该按钮只是触发该过程。Button1_Click 是一个与 DoStuff 完全不同的任务。然而，DoStuff 不仅更具描述性，而且将您的按钮与正在完成的实际工作分离。

一个好的经验法则是查看该方法是在执行某些特定于 UI 的操作，还是实际执行通用操作。例如，臀部点击方法可以处理点击或提交表单。如果是前一种，可以将其留在 button_click 处理程序中，但后者应该有自己的方法。我要说的是，牢记单一责任原则。

如果出现以下情况，我会将事件处理代码放入单独的方法中：

  • 该代码将由多个事件或从其他任何地方调用，或

  • 代码实际上与 GUI 无关，更像是后端工作。

所有小的和仅与 GUI 相关的东西总是进入处理程序，有时即使它是从同一个事件中调用的（只要签名相同）。所以更像是，如果是通用动作，就使用单独的方法，如果方法与实际事件密切相关，则不要。

于 2008-10-01T12:01:03.387 回答