事件也“做”类似方法,但它们没有返回类型和空洞?
我很想知道,为什么会这样?他们为什么不返回类型?
答案 0 :(得分:22)
因为事件可以由多个侦听器处理。事件处理程序没有保证顺序(尽管我认为它们是按照现实订阅的顺序调用的。)
相反,对于想要“返回”某些数据的事件,惯例是拥有一个可变的EventArgs对象,例如CancelEventArgs,它的Cancel属性可以设置为true。这比返回值的优点是链中的事件处理程序可以查看属性以查看是否已经设置了另一个处理程序。但是你仍然会遇到设置财产的最后一个获胜的情况。
如果它是一个返回值,那么整个概念就会复杂得多。
答案 1 :(得分:8)
实际上,事件可以具有返回值;简单地说,这不是一个好主意,因为当可能有多个侦听器时需要更复杂的处理...更常见的是,可设置的属性可能是EventArgs
子类。
但这是使用带事件的返回值的示例;这不通常是一个好主意;仅供参考:
using System;
delegate int SomeBizarreEvent(object sender); // non-standard signature
class Foo {
public event SomeBizarreEvent Bizarro;
public void TestOverall() {
SomeBizarreEvent handler = Bizarro;
if (handler != null) {
Console.WriteLine(handler(this));
}
}
public void TestIndividual() {
SomeBizarreEvent handler = Bizarro;
if (handler != null) {
foreach (SomeBizarreEvent child in handler.GetInvocationList()) {
Console.WriteLine(child(this));
}
}
}
}
class Program {
static void Main() {
Foo foo = new Foo();
foo.Bizarro += delegate { return 1; };
foo.Bizarro += delegate { return 5; };
// writes 5 (the last result wins)
foo.TestOverall();
// writes 1, 5
foo.TestIndividual();
}
}
答案 2 :(得分:3)
他们不需要。想一想。他们将返回什么?
答案 3 :(得分:0)
发射一个事件是一个单向信号。它们主要用于实现松散耦合,因为事件的提升者不依赖于消费者。返回值将创建对使用者的依赖。
答案 4 :(得分:0)
它在事件系统的设计中......事件系统的主要目的是通知而不是确认。
事件是一种向其听众(观察者)通知已发生重大行动的方法。它不是以这样的方式设计的,不仅通知听众发生了重大动作,而且还向事件源确认它是什么????被处理???或者......你怎么决定做什么???
如果事件需要返回一个值,如果没有与之关联的处理程序,它将返回它。如果一个事件有多个处理程序,那该怎么办...然后如何决定应该返回哪个处理程序值。
首先,这些事件可以返回值。虽然这不是最佳做法。
答案 5 :(得分:-2)
这是因为Event是异步调用。您可以同时处理同一事件的多个副本。
因此,他们只传递信息,以便处理事件提升者必须同步并等待事件处理程序完成的返回类型。这将使它像任何其他过程调用一样。