根据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)类型可以在多个事件之间重用。我不确定我是否将其作为一个特别好的理由来购买-尤其是鉴于仿制药-但我想这是...