c# - Button_Click 中的 "sender"(对象发送者...真的是发送者吗？

Question

Ted Faison 在 podcast on event-based software design在 .NET、C++ 和 Java 事件语句中提到了“sender”和“self”对象，例如:

private void Button_Click(object sender, RoutedEventArgs e)

是用词不当，因为例如在上面的示例中，“发送者”实际上并不是产生事件的对象，而是一个代理，因为您不想将您的应用程序耦合得那么紧密。

我是不是理解错了(因为调试的时候，“sender”确实好像是原来的对象)。

或者这些语言中的常见事件模式(例如常见的点击处理程序)是紧密耦合的，但它们应该更加解耦，例如在复合应用中。

他还提到，例如你不应该从 EventArgs 继承，因为它会导致类的爆炸式增长，每个事件一个，它只传输几个变量。在他看来，很多时候，你可以只发送一个字符串。他提到这种观点与 Microsoft 模式和实践建议的相反。

对这些领域有什么想法吗？

Answer 1

在大多数情况下，sender 是 Button (或其他)引发事件。在某些情况下，不是这种情况 - 例如(可能是懒惰的)传递事件:

class Foo {
   private Bar bar;
   public Foo(Bar bar) {
       this.bar = bar;
   }
   public event EventHandler SomeEvent {
       add {bar.SomeEvent += value;}
       remove {bar.SomeEvent -= value;}
   }
   //...
}

在这里，如果我们订阅 foo.SomeEvent，我们实际上会取回由 Bar 发起的事件。实例 - 所以 sender 不会 foo .但这可以说是因为我们已经实现了 Foo.SomeEvent不正确。

老实说，大多数情况下你不需要检查sender ;这主要是在多个控件共享一个处理程序时有用。通常，您应该能够假定发件人是您订阅的实例(出于引用相等性测试的目的)。

回复 EventArgs - 标准模式(在创建新的事件类型时)会推荐您从中继承。我不建议偏离这一点。一个次要原因是它允许您使用 EventHandler<T> ，但也有其他差异原因。此外-有时做别人期望的事情就足够了；人们期待 EventArgs衍生值(value)。

也就是说 - 我以前做过非标准事件(在 MiscUtil 的 Push LINQ 中) - 但是这已经在一个非常不寻常的设置中，所以它并没有让人觉得不合适。