既然我们有多播委托，为什么我们需要事件? [英] Since we have multicast delegates, why do we need events?

问题描述

我在一次采访中被问到这个问题，要么我正处于大脑锁定状态，要么只是愚蠢，但我没有答案.

有人吗?

Marc

I was asked this question in an interview, and either I''m suffering from brain-lock or just plain dumb, but I didn''t have an answer.

Anyone?

Marc

推荐答案

在看完您的最后一个问题后，我重新审视了您的问题.

首先要注意的是:.b中的所有委托实例绝对是多播的.我的意思是，某些委托实例在其调用列表中只有一个处理程序，但是在所有此类情况下，"+ =都会创建一个带有两个处理程序的多播接口实例.他们都有一个作为成员的调用列表，甚至是调用列表的每个成员，这都是自相矛盾的.有趣的是，"+ =绝不会向现有的委托实例添加任何内容:委托实例是不可变的.响应"+ ="，创建了一个全新的委托实例和对其的全新引用.完成委托实例的不变性是为了改善多线程.最后，为什么要谈论委托实例?采用一种委托实例. 是委托类型吗?不！委托实例的运行时类型是…类.获取类型并使用反射来查看.我在我的文章动态方法分派器 [
(惊人的逻辑:当编译器说:不允许进行操作X"时，典型的第一个问题是如何进行操作X"?我们有句谚语:如果被禁止，但非常可取的话就允许" :-).) />
事件Button.Click已在库中被调用.甚至从不需要在其他地方调用它，即使是通过从Button派生的类也是如此.一个人总是可以在两个地方调用某个方法:从Button.Click处理程序和其他地方，但是它不会导致调用(这将导致调用列表中的每个处理程序被调用)，因此不会破坏它的预期行为. UI事件系统.

调用此事件将是愚蠢的.事件就是它了:委托实例的愚蠢变体.

UI并不是事件应用的唯一领域. 在需要限制事件时使用事件.

—SA

I revisited your question after looking at your last question.

First note is: all, absolutely all delegate instances in .NET are multicast. I mean, some delegate instances have only one handler in its invocation list, but in all such cases "+=" creates a multicast interface instances with two handlers. They all have an invocation list as a member, even each member of invocation list, paradoxically. What is interesting, "+=" never adds anything to existing delegate instance: delegate instances are immutable. A brand-new delegate instances and a brand new reference to it is created in response to "+=". The immutability of delegate instance is done to improve multithreading. Finally, why do I talk about delegate instances? Take a type of a delegate instance. Is it a delegate type? No! A run-time type of a delegate instance is some… class. Get a type and use Reflection to see. I write about it in my article Dynamic Method Dispatcher[^].

Now, let''s move to events. Here is my statement: each and every behavior of events can be implemented using just delegate and delegate instances, without any exclusion. Not visa versa. So, what''s the benefits of events over delegate instances? Limitations!

For example: whatever you do, you can invoke event only in its declaring class, nowhere else. You cannot even invoke an event in a derived class, which is very unusual, because in other cases, every possibility is dictated by access modifiers and scope, nothing else. Why is that? I understood it well answering CodeProject questions. Many asked: "how can I call (I say: "invoke, not call" — SA) the event Button.Click?".

(Amazing logic: when a compiler says: "operation X is not allowed", typical first question is "how to do operation X"? We have a proverb: "If prohibited but very desirable then allowed" :-).)

The event Button.Click is already invoked — in the libraries. Invocation of it somewhere else, even through a class derived from Button is never really needed; one can always call some method in two places: from the Button.Click handler and somewhere else, but it would not cause invocation (which would cause the call of each handler in the invocation list), and hence it would not disrupt intended behavior of UI event system.

Invocation of this event would be foolish. And the event is what it is: a fool-proof variant of delegate instances.

And UI is not the only field of application of events. Events are used when the limitations of events are needed.

—SA

您是否已经知道Marc，事件机制只是委托模型上的语法糖，就像Property是getter上的语法糖一样和二传手.

正如SAKryukov正确指出的那样，事件都是关于限制的.编译器对使用``event''修饰符声明的委托实施某些限制，以便只有声明类才能调用该事件.

它还可以帮助我们(旧的VB程序员)轻松地遵循代码，您有一个心理映射，即事件表示对象中状态的改变，而委托不一定表示这一点.

Are you are already aware Marc, the event mechanism is just a syntactic sugar over the delegate model, just like a Property is a syntactic sugar over getters and setters.

As SAKryukov has rightly pointed out, events are all about restrictions. The compiler enforces certain restrictions over the delegates declared with the ''event'' modifier so that only the declaring class can invoke the event.

It also helps us (the old VB programmers) to follow the code easily, you have a mental mapping that an event signifies the change of state in an object whereas delegates do not necessarily imply that.

事件可以确保:使用+ =或-=，但不直接使用=.

Events can make sure: using += or -=, but not = directly.

这篇关于既然我们有多播委托，为什么我们需要事件?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！