这是一个很好的问题。异端，但是很好。我最近读了一篇博客文章（我找不到链接 - 有人有链接吗？）驳斥了一个神话，即为了提供良好的事件处理，你需要始终重写System.EventArgs。

我完全赞成约定和遵循规则，但我认为这个规则可以被争论为可弯曲 - 如果不是可避免的。为每个事件需要不断地重写System.EventArgs，增加了程序的耦合性 - 现在又有另一件事要跟踪了。

提供成员的“e”并不比一个命名良好的参数集更有帮助或直观。我认为不能赢得使用推荐的System.EventArgs模式的争论，但我会支持你提出这个论点。

rp

在.NET中，事件签名模式的出现主要是为了保持一致性和版本控制。通过将sender参数始终设置为System.Object，将args参数始终设置为System.EventArgs或其派生类，可以在不破坏任何现有代码的情况下更改传递给它的sender参数以及更改EventArgs类型。

整个.NET事件机制的设计目的是支持基于组件的开发，其中调用代码不受事件组件的开发者的控制。

这种设计模式的出现原因是为了解决组件化开发中的一些问题。在组件化开发中，一个组件的事件可能会被其他代码调用，而这些代码对事件组件的实现细节并不了解。为了确保事件的兼容性和扩展性，事件签名模式被引入。

事件签名模式的解决方法是将事件的参数定义为泛型的System.EventArgs或其派生类。这样一来，无论事件组件的实现如何改变，调用代码都可以保持不变。可以通过更改sender参数的类型以及更改EventArgs的派生类型来灵活地扩展和修改事件。

通过这种方式，开发者可以在不破坏现有代码的情况下对事件进行修改和扩展。无论是更改事件的发送者还是更改事件参数的类型，都不会影响到已经使用该事件的其他代码。

事件签名模式的出现是为了解决组件化开发中事件的兼容性和扩展性问题。通过将事件参数定义为泛型的System.EventArgs或其派生类，可以保持事件的一致性，并且可以在不破坏现有代码的情况下修改和扩展事件。

在C# 1.0版本中，事件签名模式并不合理。在C# 2.0版本中，由于委托的协变和逆变，事件签名模式变得更加合理。

如果你有一个事件处理方法，它并不关心参数，例如：

public void SaveDocument(object sender, EventArgs args)
{
    // 在这里保存文档
}

现在你可以使用这个方法订阅任何符合约定的事件，即使实际的发送者或参数的类型更严格。这意味着你可以将同一个处理程序用于键盘事件、按钮点击等等。

事件签名模式的出现原因是为了解决在事件处理方法中不需要关心参数的情况。通过使用泛型委托类型EventHandler，我们可以实现更灵活的事件订阅。这样，我们可以将一个通用的事件处理方法应用于多个事件，而不必为每个事件编写特定的处理方法。

解决方法是使用泛型委托类型EventHandler来定义事件处理方法的签名。这个委托类型接受两个参数，一个是事件发送者的对象，一个是用于传递事件数据的参数对象。通过使用泛型类型参数TEventArgs，我们可以根据具体事件的需求来定义参数类型。

通过这种方式，我们可以更加灵活地订阅和处理事件，而不必为每个事件编写特定的处理方法。这大大简化了事件处理的代码，并提高了代码的可重用性和可维护性。

总之，事件签名模式的出现和解决方法使得事件处理更加灵活和高效，提高了代码的可重用性和可维护性。