我应该使用 EventArgs 还是简单的数据类型？
我目前正在创建一个用于娱乐和练习的库，我想知道在引发事件时，如何在传递您自己的 EventArgs 导数或仅传递数据类型之间进行选择。
例如，在我的图书馆中，我有这样的内容：
public delegate void LostConnectionEventHandler(string address);
public delegate void MessageReceieved(byte[] bytes);
这的标准做法是什么？我应该将 string address 替换为 ConnectionEventArgs 并将 byte[] bytes 替换为 MessageEventArgs 吗？
我知道其中任何一个都可以正常工作，并且这个问题可能是主观的，但我仍然对高级程序员在决定是否包含自己的 EventArgs 还是直接传递数据时所经历的思维过程感到好奇。
谢谢！
I'm currently creating a library for fun and practice and I was wondering, when raising an event, how to choose between passing your own EventArgs derivative or just the data type.
For example, in my library I have something like this:
public delegate void LostConnectionEventHandler(string address);
public delegate void MessageReceieved(byte[] bytes);
What is the standard practice for this? Should I replace string address with ConnectionEventArgs and byte[] bytes with MessageEventArgs?
I know either one works just fine and this question may be subjective but I am still curious on the thought process higher-level programmers go through when deciding whether or not to include their own EventArgs or just to pass the data in directly.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
在我的项目中，当参数数量大于 1 时，我使用 EventArgs！查看 NotifyPropertyChanged 事件，它有一个参数，该参数不是 EventArgs 类型。
Within my projects I use EventArgs when the number of parameters is larger than one! Look at the NotifyPropertyChanged Event, it has one argument, which isn't an EventArgs type.
无需从
EventArgs派生，但约定遵循常见的 (引入参数对象< /a>) 重构规则。这条规则的基本原理是有据可查的。There's no need to derive from
EventArgshowever the convention follows the common (Introduce Parameter Object) refactoring rule. And the rationale for this rule is well documented.我通常不同意“隐藏你的参数”准则。在人为的对象中隐藏参数会从事件签名中删除很多含义和上下文，从而使开发人员寻找它。为什么？只是为了避免我们一直使用方法做的事情：添加参数时更新调用站点。这没什么大不了的。如果是的话，我们还会将方法参数隐藏在“MethodArgs”参数中。在大多数情况下，可读性的损失是不值得的。
I generally disagree with the "hide your args" guideline. Hiding arguments in a contrived object removes a lot of meaning and context from the event signature, making developers hunt for it. And why? Just to avoid something we do all the time with methods: update call sites when an argument is added. That's just not a big deal. If it were, we'd also hide method arguments in a "MethodArgs" parameter. The readability loss isn't worth it in most cases.
参考： http://msdn.microsoft.com/ en-us/library/aa645739(v=vs.71).aspx
另一个有用的信息：http://msdn.microsoft.com/en-us/library/ms229011.aspx
Reference: http://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx
Another useful information: http://msdn.microsoft.com/en-us/library/ms229011.aspx
就我个人而言，我喜欢从
EventArgs派生的想法，如果您必须传递状态信息和聚合对象，您可以轻松做到这一点，请参阅
MouseEventArgs 类型。
使用 OOP 方法，如果您有一个接受
EventArgs类型的对象的事件/构造，您可以相信从它派生的每个对象都将以相同的方式工作，而如果您有另一种类型的对象，则可以使用 OOP 方法。如果对象不共享相同的基类，您最终可能会破坏某些东西。很难证明和重现，但可能取决于设计，因为事件是设计用于与
EventArgs及其后代一起使用的特殊委托Personally I like the idea of deriving from
EventArgs,if you have to pass status information and aggregate objects you could easily do it, see the
MouseEventArgs type for example.
using OOP approach, if you have an event/construct which accepts an object of type
EventArgsyou can rely on the fact that every object derived from it will work in the same way while if you have another kind of object which does not share the same base class, you could eventually break something.hard to prove and reproduce but possible depending on the design, because events are special delegates designed to work with
EventArgsand its descendants在较大的项目中，当事件在某些情况下需要附加数据时，拥有 EventArgs 类有助于最大限度地减少必须修改的代码。我通常更喜欢 EventArgs 方式而不是直接值。
In a larger project, having an EventArgs class, helps with minimizing the code you have to modify, when your event needs additional data in some cases. I usually prefere the EventArgs way instead of a direct value.