事件的发送者是否应该始终是通用对象？

使用C＃编写事件时，建议以以下形式创建委托：

delegate XEventHandler(object sender, XEventArgs e);

我的问题是关于代表的第一个论点object sender。一定要一定要通用object吗？具有类型的发送方object总是会导致与此类似的代码。

val = ((ConcreteType)sender).Property;

或者，甚至更冗长，

ConcreteType obj = sender as ConcreteType
if (obj != null) { ... }

反对强类型发送者的一种说法是，其他对象可以转发事件而不必担心类型。尽管这在GUI环境中可能有意义，但是我不确定它是否可以在GUI之外受益。

如果始终知道发送方的类（至少是抽象类）怎么办？例如，如果我实现ListChanged的一个抽象事件List类，而如果其他类要继承它（例如LinkedList，ArrayList），是这一切的权利界定与类型的发件人我的委托List？

delegate ListChangedEventHander(List sender, ListChangedEventArgs e);

还是将常规object sender类型更改为更特定的类型会有不利影响？

在这一点上，它通常是（相当强的）约定。也就是说，如果您编写的库不遵循该约定，那将很奇怪。

该事件设计指南说：

不要将其object用作事件处理程序的第一个参数的类型，并将其称为sender。

但是，您可能会注意到，当前指南指出，您不应为事件定义自己的自定义委托，而应尽可能使用EventHandler<T>它。

对于设计，我猜想它即使在事件的原始设计者最初未预想到的上下文中也可以促进事件处理程序的重用。

提出此建议的原因是，它允许将来的更改，而这些更改不一定需要更改现有代码，尤其是公共接口。

事件机制本身仍然可以用于“ VB6”样式的事件，但是如果您需要更改签名（或者更糟：创建相同事件的新版本），则必须更改所有现有使用者。使用推荐的方法，只要较新的项目继承自现有项目，就可以在不修复现有代码的情况下更新签名。