将事件处理代码放入自己的方法中是一个好的设计吗？

Question

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

引发的点击事件通常绑定到

等方法

  

protected void Button1_Click（对象   发件人，EventArgs e）{

     

}

我在其他人的代码中有时看到的是，按钮行为的实现不是放在Button1_Click方法中，而是放在一个自己的方法中，就像这样从这里调用：

  

私人DoStuff（）{}

     

protected void Button1_Click（对象   sender，EventArgs e）{       this.DoStuff（）;   }

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

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

Answer 1

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

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

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

Answer 2

一个好的经验法则是查看该方法是否正在执行某些特定于UI的实际操作。例如，臀部点击方法可以处理单击或提交表单。如果它是前者，可以将它留在button_click处理程序中，但后者应该有自己的方法。我只是说，记住single responsibility principle。

Answer 3

在这种情况下，我会保留DoStuff（）方法但是订阅它：

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

不可否认，那些在设计师中完成所有活动布线的人都不会满意......但我觉得个人检查更简单。 （我也讨厌自动生成的事件处理程序名称......）

Answer 4

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

  

一个好的经验法则是看是否   该方法正在做一些UI   具体的，或实际实施的   一般行动。例如臀部   click方法可以处理一个   点击或提交表格。如果它的   以前的那种，它可以留在它   button_click处理程序，但后者   值得一个自己的方法。我只是   说是，保持单身   责任原则。

     

我将事件处理代码放入   单独的方法如果：

     

  

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

  

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

  

     

一切都很小   只要   GUI相关总是进入   处理程序，有时即使它正在存在   从同一事件中调用（只要   签名是一样的）。所以这是   更像是，如果它使用单独的方法   是一般性行动，如果不是   方法与此密切相关   实际活动。