情况

Question

情况

这是一个概念性问题，我将尽可能清楚地表达。如果您对概念性问题不感兴趣，请不要阅读该问题。

好的，所以我正在编写一些预先编写的代码，在这段代码中，他们将事件处理程序重用为某种形式的OOP。

某个事件处理程序的示例：

protected void btnSomeButton_Click(object sender, Eventargs e)
{
    //SOME LOGIC
}

＆＃34;重复使用＆＃34;上面的事件处理程序：

注意：在Web App中的任意一点调用它，重用// SOME LOGIC部分。

{
    btnSomeButton_Click(null, null);
}

为了清晰起见，有些要点

上述方法有效。
事件处理程序正常工作。

我认为应该做什么

根据我的推理，正确的方法是创建一个单独的方法，并在尝试重用代码时调用此方法。（随意纠正我）

protected void btnSomeButton_Click(object sender, EventArgs e)
{
    somefunction();
}

并重用代码：

{
    somefunction()
}

方法是这样的：

void somefunction()
{
    //SOME LOGIC
}

问题|我的问题

我希望能够告诉我的上级我为什么要更改此代码。他们所看到的只是这段代码有效，并且＃34;伟大的＆＃34;，但看着这种编码风格会伤害我的眼睛。

第一个例子编码方式不编码的概念原因是什么？或者这是可以接受的，我应该离开吗？

Answer 1

事件处理程序是松散耦合的，即触发事件的代码在注册后者之前不知道它的调用方法。

如果然后从代码中的其他地方调用该方法，通过将其作为Action<object, EventArgs>传入，然后以这种方式调用它，调用代码在注入之前仍然不知道该方法，所以它仍然松散耦合。

直接调用事件处理程序，但将事件处理程序与调用代码紧密耦合。如果您想稍后更改事件处理程序，您最终可能会破坏该代码，并且您必须首先检查对它的所有引用（可以在整个代码中传播）。测试变得更加困难，因为紧密耦合的代码本身更难以分成单元，因此测试变得更加复杂，需要更多的模拟并且更加脆弱。

事件处理程序应该是私有的，只能通过“告诉，不要问”（例如，通过针对事件进行注册）暴露给代码的其他部分。

Answer 2

我同意你将代码放入单独功能的理由我在处理这些类型的重用时遇到的主要问题是，通常不期望看起来像框架事件的处理程序的东西被其他东西调用框架示例中的参数表示非常重要的一点：现在它们未被使用，但将来可能会发生变化。框架通常会为参数提供某些保证，例如它们永远不会是null：编辑代码时，可能会说“我为什么不信任框架？”并省略任何null检查。然后，对于只传递null的非框架代码，这将失败我经常遇到的另一个问题是，在“手动”调用的情况下，处理程序可以在以后使用不可取或甚至有害的代码进行扩展。想到一个简单的例子就是记录类似“用户点击按钮”的内容，而事实上用户却没有。

我更喜欢将在框架处理程序中执行的每个操作放入其自己的函数中，该函数具有明确的名称并且可以单独调用。

使用事件处理程序作为＆＃34;可重复使用的代码＆＃34;不好的做法？

情况

我认为应该做什么

问题|我的问题

2 个答案: