.NET 中的代码友好版本的事件签名

Question

以前的帖子：

Event Signature in .NET — Using a Strong Typed 'Sender'?

In a C# event handler, why must the “sender” parameter be an object?

---

Microsoft 的约定和准则强制 .NET 用户使用特殊模式在 .NET 中创建、引发和处理事件。

活动设计指南http://msdn.microsoft.com/en-us/library/ms229011.aspx 声明

---

引用：

事件处理程序签名遵循以下约定：

• 返回类型为 Void。

• 第一个参数命名为sender 并且是对象类型。这是 引发事件的对象。

• 第二个参数名为 e 和 是 EventArgs 类型或派生的 EventArgs 的类。这是 特定于事件的数据。

• 该方法恰好需要两个 参数。

---

这些约定告诉开发人员（以下）更短且更明显的代码是邪恶的：

public delegate void ConnectionEventHandler(Server sender, Connection connection);

public partial class Server
{
    protected virtual void OnClientConnected(Connection connection)
    {
        if (ClientConnected != null) ClientConnected(this, connection);
    }

    public event ConnectionEventHandler ClientConnected;
}

并且（以下）更长且不太明显的代码很好：

public delegate void ConnectionEventHandler(object sender, ConnectionEventArgs e);

public class ConnectionEventArgs : EventArgs
{
    public Connection Connection { get; private set; }

    public ConnectionEventArgs(Connection connection)
    {
        this.Connection = connection;
    }
}

public partial class Server
{
    protected virtual void OnClientConnected(Connection connection)
    {
        if (ClientConnected != null) ClientConnected(this, new ConnectionEventArgs(connection));
    }

    public event ConnectionEventHandler ClientConnected;
}

尽管这些指南没有说明为什么遵循这些约定如此重要，但让开发人员表现得像猴子一样，不知道他们为什么要做什么。

恕我直言，Microsoft 的 .NET 事件签名约定对您的代码不利，因为它们会导致在编码、编码、编码上花费额外的零效率工作：

1. 编码“(MyObject)sender”转换（不是说 99% 的情况根本不需要发送者）
2. 为要在事件处理程序内部传递的数据编码派生的“MyEventArgs”。
3. 编码取消引用（在需要数据时调用“e.MyData”，而不仅仅是“数据”）

做到这一点并不难，但实际上，如果不遵守微软的惯例，我们会失去什么，除了人们认为你是异端，因为你的行为违反了微软的惯例verges on blasphemy :)

你同意吗？

Answer 1

关于有一个强类型的发件人，我自己也经常想知道。

关于 EventArgs，我仍然建议您使用中间 EventArgs 类，因为您可能希望在未来添加当前无法预见的事件信息。如果您一直使用特定的 EventArgs 类，您可以简单地更改类本身以及触发它的代码。如果您按照示例传递连接，则必须重构每个事件处理程序。

编辑

Jim Mischel 在他的 cmets 中提出了一个很好的观点。通过将发件人设为object，我们可以使相同的事件方法潜在地被重用于处理各种事件。例如，假设网格需要更新自身，如果：

• 用户单击“刷新”按钮，或
• 系统检测到从服务器加载了一个新条目。

你可以这样说：

serverBus.EntryReceived += RefreshNeededHandler;
refreshButton.Click += RefreshNeededHandler;

...
public void RefreshNeededHandler(object sender, EventArgs args) 
{
    ...
}

当然，在实践中，我几乎从未呼吁过这种重用，而在很多很多情况下，我倾向于将sender 转换为我知道的对象类型必须。如果我想重用这样的处理程序，我认为制作两个都调用相同便捷方法的处理程序会很容易。对我来说，事件处理程序在概念上应该处理特定对象组上的特定类型的事件。所以我个人并不认为object sender 方法是最好的约定。

但是，我可以想象这会非常方便的情况，例如，如果您想记录每个被触发的事件。

Answer 2

你会遇到的问题：

1. 当您添加另一个参数时，您 将不得不改变你的活动 处理程序签名。

2. 当程序员第一次看到 您的代码，您的事件处理程序将 看起来不像事件处理程序。

尤其是后者比编写一个 5 行的类会浪费你更多的时间。

Answer 3

我发现不遵循约定的最大问题是，您会让习惯于以运行时库的方式处理事件的开发人员感到困惑。我不会说约定是好是坏，但它肯定不是邪恶。 .NET 开发人员知道并了解如何处理按照 Microsoft 指南编写的事件。在此基础上创建自己的事件处理机制可能在运行时更有效，甚至可能导致您认为更干净的代码。但它会有所不同，您最终会在程序中使用两个事件处理“标准”。

我的立场是，使用一个不太理想的标准（只要它没有被严重破坏）比使用两个相互竞争的标准要好。

Answer 4

我使用了强类型事件（而不是对象，因为这样我就不必进行强制转换了），这真的不难理解，“哦，看他们使用了不是对象的类型”

对于 eventArgs，您应该使用它以防对象根据@StriplingWarrior 的回答发生变化。

我不明白为什么开发人员会对此感到困惑？