Question

我最近看到一些大学老师的代码，他有类似的东西：

public void Button1_Click(blabla)
{
   //His code was here.
}

调用方法来执行脏工作是不是更好的编程实践，这样如果方法更改，您只需要更改方法本身而不是事件？（减少破坏的可能性）

public void Button1_Click(blabla)
{
   DoSomething();
}

public void DoSomething()
{
   //The actual code here.
}

Answer 1

您只需要提取DoSomething if

a）在其他地方需要它的功能，或者可能

b）这是一段相当长的代码。

如果事件是唯一使用它的地方，那么就没有必要提取它。

Answer 2

将它们分开是有一定意义的，如果你想从其他地方调用DoSomething（那里提供发送者和事件args是没有意义的话），这是非常有用的。 / p>

然而，这里有一个更好的选择 - 至少如果你是以编程方式订阅的话。改为使用匿名方法或lambda表达式：

button.Click += delegate { DoSomething(); }

然后，在订阅时明显看出你没有使用其他参数，而且你不会浪费额外的方法。

这样做的缺点是它无法与Visual Studio的设计器生成的事件订阅一起使用。就个人而言，我希望Visual Studio支持使用没有所有委托参数的方法订阅事件 - 它可以自动生成匿名方法（或lambda表达式）。这将是两个世界中最好的，IMO。

正如其他答案所说，如果您不需要从其他任何地方调用它，我认为将方法体保留在事件处理程序方法本身是合理的。

Answer 3

不，不一定。

除非您在代码中的其他位置使用DoSomething()，否则将其分解为单独的方法确实没有意义。

Button1_Click本身就是一种方法。它恰好是与click事件委托匹配的生成标头。你可以随心所欲地创造这个名字，然后就会以你想要的方式继续工作。

Answer 4

该方法的内容是什么？如果它与UI非常明显相关（例如更新Visible / Enabled状态）并且不从其他任何地方调用，那么您也可以将其留在处理程序中。但是，如果该方法正在为您的数据/逻辑层做事，而不是委托给那些层中的函数调用，那么可能值得打破一些逻辑并可能将其移动到不同的层。我必须从多个事件处理程序更新相同或类似的状态时，唯一一次将严格的UI相关代码分支到自己的方法。

Answer 5

我个人认为这取决于代码的长度以及代码是否在逻辑上位于那里。

所以，如果它只有1或2行，那么我在里面做，但如果它的代码更多，我会用另一种方法做。

Answer 6

是的，额外的方法是“更好”，但你必须权衡YAGNI（你不需要它）反原则。

有两个 reaons 额外的方法被认为更好：

这样可以更轻松地重构在多个地方使用的行为
它可以更容易地分离出在完全不同的应用程序中使用的行为

这两者都归结为封装和将事件与事件分离的想法。以后来这个代码的人都不会重构以删除额外的方法，但是没有额外方法来到代码的人可能会重构以添加它。但是再次 - YAGNI。

Answer 7

如果你不打算重用代码，那么它没有什么区别 - 它只是开销。如果您打算从代码中的其他位置调用“DoSomething（）”，那么请务必将其抽象出来。

Answer 8

如果它是可重复使用的代码，则将其放在外面。还有一些编码指南，检查你公司的政策，强迫你选择第二种风格。

Grz，Kris。

Answer 9

大多数现代设计方法（例如，MVC，MVVM）在事件处理程序中只有最少的代码，将所有程序逻辑传递给单独的（可测试单元的）类。

然而，对于课堂教学（或演示代码），我认为直接使用事件处理程序并没有错。

在事件中编写方法体是否可以？

9 个答案: