c# – 为什么MSDN建议在委托声明中包含对象发送者？

发布时间：2020-12-15 17:14:50 所属栏目：百科来源：网络整理

导读：我正在阅读 this页面,我注意到它是如何说这是标准指南： The .NET Framework guidelines indicate that the delegate type used for an event should take two parameters,an “object source” parameter indicating the source of the event,and an “e”

我正在阅读 this页面,我注意到它是如何说这是标准指南：

The .NET Framework guidelines indicate that the delegate type used for an event should take two parameters,an “object source” parameter indicating the source of the event,and an “e” parameter that encapsulates any additional information about the event.

我可以理解在某些情况下如何让对象发送者有用,但我可以在其他情况下看到完全相反的情况.例如,

>如果处理该事件的班级不应该知道是谁解雇了该怎么办？耦合,凝聚力以及所有这些.
>就我而言,我已经将对象引用为成员变量.这就是我订阅活动的方式.它只会有一个实例,因此没有理由转换发送者对象而不仅仅是使用成员变量.
>在我的程序中,发件人对象根本不应该为客户端所知.很难解释我在做什么,但基本上我在一个库中有一个内部构造函数的类,该库也被该库中的另外两个类使用.我的客户端类正在订阅来自这两个类的事件,但事件最初是从客户端不应该知道的内部类调用的.
>这对事件处理程序的客户来说很困惑.库应该易于理解,在我的情况下,没有理由使用sender变量.没有.那为什么要包括它呢？

话虽如此,为什么微软表示事件处理程序应遵循这些指导原则？难道不总是最好的选择吗？

编辑：感谢大家的回复.我决定采用大多数人并使用EventHandler< T>我在这个图书馆的所有活动.

解决方法

我认为该模式的原因是强制执行一些一致性. sender参数允许为多个发布者(按钮,表)重用单个处理程序.

解决你的观点：

1)根本不使用它.这很常见,并没有真正伤害任何良好的做法.

2)没关系,再次忽略发件人

3)完全矛盾你所说的2)…
其余的与1)相同.你甚至可以考虑将null作为发送者传递.

4)“那么为什么要包括它” – 还有其他用例需要发送者.

但请注意,这只是图书馆确认BCL的指南.您的案例听起来更像是一个特定的应用程序(而不是库),所以请随意使用您喜欢的任何参数方案.编译器不会抱怨.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!