是“发送者”吗？在 Button_Click(对象发件人...真的是发件人吗？

发布于 2024-07-15 11:07:21 字数 590 浏览 5 评论 0原文

Ted Faison 在关于基于事件的软件设计的播客中提到“发送者” .NET、C++ 和 Java 事件语句中的“self”对象，例如：

private void Button_Click(object sender, RoutedEventArgs e)

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

我是否对他理解错误（因为当我调试它时，“sender”确实似乎是原始对象）。

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

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

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

原文

Ted Faison in a podcast on event-based software design mentioned that "sender" and "self" objects in .NET, C++ and Java event statements such as:

private void Button_Click(object sender, RoutedEventArgs e)

are a misnomer since e.g. in the above example "sender" is not really the object which produced the event but a proxy, since you wouldn't want to couple your applications that tightly.

Did I understand him incorrectly (since when I debug it, "sender" does indeed seem to be the original object).

Or is it that common event patterns in these languages (e.g. a common click handler) are tightly coupled but they should be more decoupled, e.g. in composite applications.

He also mentioned that e.g. you shouldn't make inherit from EventArgs since it leads to an explosion of classes, one per event, which only transport a few variables. Many times in his opinion, you can just send a string for instance. He mentioned that this opinion is the opposite of what Microsoft Patterns and Practices suggests.

Any thoughts on these areas?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

微暖i 2024-07-22 11:07:21

在大多数情况下，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；主要有用的时候是当多个控件共享一个处理程序时。您通常应该能够假设发送者是您订阅的实例（出于引用相等测试的目的）。

Re EventArgs - 标准模式（当创建新的事件类型时）会建议您继承此模式。我不建议偏离这一点。一个次要原因是它允许您使用 EventHandler，但还有其他差异原因。此外，有时做别人期望的事就足够了；人们期望一个EventArgs派生值。

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

In most cases, sender is the Button (or whatever) that raised the event. There are some occasions when this isn't the case - such as a (perhaps lazy) pass-thru event:

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

Here, if we subscribe to foo.SomeEvent, we will actually get back the event originated by the Bar instance - so sender won't be foo. But this is arguably because we've implemented Foo.SomeEvent incorrectly.

To be honest, in most cases you don't need to check sender; the main time this is useful is when a number of controls share a handler. You should generally be able to assume the sender is the instance you subscribed to (for the purposes of reference-equality tests).

Re EventArgs - the standard pattern (when creating a new event-type) would recommend you to inherit from this. I don't recommend deviating from this. A minor reason is that it allows you to use EventHandler<T>, but there are other variance reasons too. Besides - sometimes doing what other people expect is reason enough; people expect an EventArgs derived value.

That said - I have done non-standard events before (in MiscUtil's Push LINQ) - but this was already in a very unusual setup, so it didn't feel out of place.

回复收藏 0 原文

绿萝 2024-07-22 11:07:21

首先 - “发送者”将保存对您单击的按钮的引用。如果您有多个按钮都连接到同一事件，则可以通过以下方式查看您点击了哪个按钮（如果您没有在事件参数中传递某些内容来读取此内容）。

另外，我在某种程度上同意编写继承 frmo EventArgs 的新 eventargs 可能会导致类爆炸 - 因此请谨慎使用。我喜欢只引发 EventArgs.Empty，然后让代码捕获事件，显式查询引发数据事件的对象。我的意思是 - 一旦你捕获了事件，你就可以转到引发事件的对象并读取你感兴趣的属性，而不是从事件参数中读取数据。这样可以更轻松地读取你需要的内容，但是当然 - 您可能会发现自己处于这样的情况：这些属性在引发事件和您读取属性之间发生了变化。

回复收藏 0 原文

~没有更多了~