事件订阅者是否按订阅顺序调用？

发布于 2024-07-10 02:18:36 字数 343 浏览 9 评论 0原文

假设事件订阅者按订阅顺序调用是否安全？
示例：

void One(object sender, EventArgs e) {}
void Two(object sender, EventArgs e) {}

event EventHandler foo;

foo += One;
foo += Two;

事件触发时，One() 是否总是在 Two() 之前调用？

编辑：
你当然不应该依赖它，我只是在想。这个想法是，多播委托类似于命令模式。所以我只是想知道。通常，您会使用一个集合来保留命令的顺序，以便您可以执行撤消/重做/任何操作。

原文

Is it safe to assume that event subscribers are called in order of subscription?
Example:

void One(object sender, EventArgs e) {}
void Two(object sender, EventArgs e) {}

event EventHandler foo;

foo += One;
foo += Two;

Is One() always called before Two() when the event is fired?

Edit:
You should ofcourse not rely on it, I was just thinking. The idea was, that multicast delegates are similary to the COMMAND pattern. So I was just wondering. Ususally you would use a collection that keeps the order for COMMANDs so you can do undo/redo/whatever.

分享到QQ

分享到微博

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

发布评论

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

下壹個目標 2024-07-17 02:18:36

鉴于该实现，是的，它们将始终按该顺序调用。

如果事件实际上使用某种奇怪而美妙的方式来处理订阅，它可能会做不同的事情 - 但“正常”实现会做正确的事情。

需要明确的是，订阅事件处理程序仅意味着调用事件的适当“添加”部分。如果事件通过执行以下操作来处理此问题：

myHandler += value;

则会被转换为

myHandler = Delegate.Combine(myHandler, value);

Delegate.Combine< /a> 保证顺序。但是，如果您有一个像这样的事件：

private LinkedList<EventHandler> eventHandlers = new LinkedList<EventHandler>;

public event EventHandler Foo
{
    add
    {
        eventHandlers.AddFirst(value);
    }
    remove
    {
        // do stuff here too
    }
}

然后通过执行类似以下操作来触发该事件：

foreach (EventHandler handler in eventHandlers)
{
    handler(this, EventArgs.Empty);
}

那么处理程序将以相反的顺序被调用。

摘要：对于所有理智的事件，您都可以依赖顺序。理论上，事件可以做它们想做的事，但我从未见过一个事件不保持适当的顺序。

Given that implementation, yes, they will always be called in that order.

If the event actually uses some weird and wonderful way of handling subscriptions, it could do different things - but "normal" implementations will do the right thing.

To be clear, subscribing to an event handler just means invoking the appropriate "add" part of an event. If the event handles this by doing something like:

myHandler += value;

that gets translated into

myHandler = Delegate.Combine(myHandler, value);

and Delegate.Combine guarantees the ordering. However, if you had an event like this:

private LinkedList<EventHandler> eventHandlers = new LinkedList<EventHandler>;

public event EventHandler Foo
{
    add
    {
        eventHandlers.AddFirst(value);
    }
    remove
    {
        // do stuff here too
    }
}

and then fired the event by doing something like:

foreach (EventHandler handler in eventHandlers)
{
    handler(this, EventArgs.Empty);
}

then the handlers would be called in the reverse order.

Summary: For all sane events, you can rely on the ordering. In theory, events can do what they like, but I've never seen an event which doesn't maintain the appropriate ordering.

回复收藏 0 原文