根据Microsoft event naming guidelines的说法,C#事件处理程序中的sender参数“即使可能使用更具体的类型,也始终是对象类型”。

这导致许多事件处理代码,例如:

RepeaterItem item = sender as RepeaterItem;
if (item != null) { /* Do some stuff */ }

为什么约定不建议使用更具体的类型声明事件处理程序?
MyType
{
    public event MyEventHander MyEvent;
}

...

delegate void MyEventHander(MyType sender, MyEventArgs e);

我想念陷阱吗?

对于后代:我同意以下观点:在可能的情况下,即使可能使用更具体的类型,约定也应使用对象(并通过EventArgs传递数据),在现实世界编程中,遵守惯例。

编辑:搜索诱饵:RSPEC-3906规则“事件处理程序应具有正确的签名”

最佳答案

好吧,这是一种模式,而不是规则。这确实意味着一个组件可以从另一个组件转发事件,即使不是引发该事件的普通类型,也可以保留原始发送者。

我同意这有点奇怪-只是出于熟悉的缘故,值得遵循惯例。 (也就是说,对其他开发人员很熟悉。)我从来没有特别热衷于EventArgs(因为它本身不传达任何信息),但这是另一个主题。 (至少现在我们有了EventHandler<TEventArgs> -尽管如果在普通情况下也需要EventArgs<TContent>来传播单个值,这会有所帮助。)

编辑:当然,这确实使委托(delegate)更具通用性-单个委托(delegate)类型可以在多个事件之间重用。我不确定我是否将其作为一个特别好的理由来购买-尤其是鉴于仿制药-但我想这是...

10-07 19:35
查看更多