在构造函数中注册事件？

我一直在玩代表，活动和匿名方法。这样做有一点变得非常清楚。在构造函数中注册事件？

它不简化在构造函数中注册任何事件方法或委托函数的过程吗？

我的测试显示它的工作原理，它可以防止你必须在实例化后声明它们（因为对象的构造函数为你做）。

其实这个表现还是不错的。在构造/实例化对象时使用“this”关键字引用当前对象有什么缺点吗？

这似乎对我很有意义，因为所有的事件都会在实例化时被连接起来。

这有可能是一个问题吗？

例子：

//Constructor 
public SayHello() 
{ 
    _name = "Unnamed"; 
    _isUpdated = false; 

    // Register event handler via lambda (ananymous method shorthand) 
    this.NameChanged += (object sender, EventArgs e) => { Console.WriteLine(e.message)); }; 
}

来源

2011-12-09 Qubits

这种方法存在一些潜在的问题。首先，从更广泛的角度来看，出于性能原因，通常应该使用方法覆盖来订阅自发布事件。很明显，如果事件被暴露于没有相应的可重写方法的事件的基于外部的基类暴露，这是不可能的。但是，订阅自发布事件应该是最后的方法，而不是默认方法。

第二个潜在的问题更严重，但它与事件触发的代码的作用有关，而不是哪个对象公开事件。例如，考虑下面的构造：

public Foo(Bar bar) 
{ 
    bar.SomeEvent += (s, e) => this.DoSomething(); 
}

如果酒吧火灾在另一个线程SomeEvent，你的Foo实例的DoSomething的方法可以被称为实例已完全初始化之前。在Java空间中这是一个相当有据可查的问题（例如，请参阅http://www.ibm.com/developerworks/java/library/j-jtp0618/index.html），但C＃/ .NET的覆盖范围更加稀疏。 http://www.bluebytesoftware.com/blog/2010/06/27/OnPartiallyconstructedObjects.aspx提供了一些详细的.NET覆盖，但它可能比你想知道的要多...

来源

2011-12-09 13:47:58

妮可，优秀点。这正是我所期待的。我的直觉告诉我，增加的简化可能是有问题的（因此后）。在测试中，事情可能很好，但在生产中，墨菲的定律将会生效......概率上，任何可能发生的事情都会给予足够的时间。鉴于此，如果所述应用程序是多线程的（如服务或Web门户），则会在某个时间点发生竞争争用。谢谢。 – Qubits

我不认为有任何问题。这取决于你如何做到这一点。您可以在其构造函数中使用该对象本身。如果你忽略了this，它也可以工作。

来源

2011-12-09 12:28:20 Fischermaen

这就是我的想法。我发现它非常“不”必须在客户端声明事件（假设对象可以实例化所有代码）。这就是说，只是在寻找任何潜在的陷阱来考虑。到目前为止，我还没有遇到任何其他内存使用情况（只有在事件不相关的情况下才需要关注）。 – Qubits

在构造函数中注册事件？

回答

相关问题