Question

考虑以下事件处理程序

Private Sub ProfileSelectCheckBox_CheckedChanged(sender As Object, e As EventArgs) Handles ProfileSelectCheckBox.CheckedChanged
    ProfilesComboBox.Enabled = ProfileSelectCheckBox.Checked
End Sub

在这个处理程序中，我根本不使用sender，但是我看到很多人都在谈论投射sender的模式。在我的情况下，我最终会得到一些尴尬的代码，因为处理程序没有传递给ProfilesComboBox的对象引用。

ProfilesComboBox.Enabled = DirectCast(sender, CheckBox).Checked

如果在运行时为另一个CheckBox添加了这个处理程序，我最终会得到一些有或没有强制转换的破坏代码，这让我相信最好将处理程序定义的范围限制在方法内部无论如何要将它从外面隐藏起来，但也许这有点偏离主题。

在这个简单的例子中，我认为不需要演员。我的问题是，这是不赞成/不好的做法，还是只是简单到让它通过？

Answer 1

我认为根本不需要使用发件人，更不用说投了它。如果你想要一个通用事件处理程序转换可能会有所帮助，但是对于像你的样本那样具体的东西它没用。

然而，链接控件的更好方法可能是使用MVP模式，这将使您的示例中的行为更易于测试。

Answer 2

 Private Sub Yadayada(...) Handles ProfileSelectCheckBox.CheckedChanged

不，很明显发件人是谁。毫无疑问，它是ProfileSelectCheckBox。因为这是您在 Handles 子句中命名的控件。投射发件人没有意义，也可以直接在代码中使用ProfileSelectCheckBox。

这是您编写的事件处理程序的明显用法，许多事件处理程序都是这样的。但它不仅限于此。 Handles 关键字接受多个事件源。您也可以这样写：

Private Sub Yadayada(...) Handles ProfileSelectCheckBox.CheckedChanged, _
                                  UserSelectCheckBox.CheckedChanged

哪个是具有CheckChanged事件处理程序的两个控件的事件处理程序。显然，您现在对 sender 参数更感兴趣，它允许您区分ProfileSelectCheckBox和发出相同CheckChanged事件的UserSelectCheckBox之间的区别。

您可以无休止地扩展它，为 Handles 子句添加越来越多的事件源。或者，您可以在代码中使用AddHandler语句，而无需使用Handles关键字。

这里的显着特点是，当您使用Winforms设计器时，不会发生这种情况。当您编写自己的代码而不是将其留给代码生成器时，就会发生这种情况。这是一次精神上的飞跃，这是非常重要的一次。它使你成为真正的程序员，不再使用为你生成代码的机器人。

恭喜并欢迎参加聚会。

是否始终需要在事件处理程

2 个答案: