集中事件发送的利弊

Question

我正在考虑在C++应用程序中实现事件的不同方法.有人建议通过通知中心实施集中的事件调度.另一种方法是将事件的来源和目标直接通信.不过,我对通知中心方法有所保留.我会在我看到它们时概述这两种方法(我很可能会误解它们,我以前从未实现过事件处理).

a)直接沟通.事件是其源接口的一部分.对事件感兴趣的对象必须以某种方式获取源类的实例并订阅其事件:

struct Source
{
    Event</*some_args_here*/> InterestingEventA;
    Event</*some_other_args_here*/> InterestingEventB;
};

class Target
{
public:
    void Subscribe(Source& s)
    {
        s.InterestingEventA += CreateDelegate(&MyHandlerFunction, this);
    }

private:
    void MyHandlerFunction(/*args*/) { /*whatever*/ }
};

(根据我的理解,boost :: signals,Qt信号/插槽和.NET事件都是这样的,但我可能是错的.)

b)通知中心.事件在其源代码界面中不可见.所有事件都发送到一些通知中心,可能是作为单身人员实施的(任何关于避免这种情况的建议都会受到赞赏),因为他们被解雇了.目标对象不必知道任何有关源的信息; 他们通过访问通知中心订阅某些事件类型.一旦通知中心收到新事件,它就会通知所有对该特定事件感兴趣的订户.

class NotificationCenter
{
public:
    NotificationCenter& Instance();

    void Subscribe(IEvent& event, IEventTarget& target);
    void Unsubscribe(IEvent& event, IEventTarget& target);

    void FireEvent(IEvent& event);
};

class Source
{
    void SomePrivateFunc()
    {
        // ...
        InterestingEventA event(/* some args here*/);
        NotificationCenter::Instance().FireEvent(event);
        // ...
    }
};

class Target : public IEventTarget
{
public:
    Target()
    { 
        NotificationCenter::Instance().Subscribe(InterestingEventA(), *this); 
    }

    void OnEvent(IEvent& event) override {/**/}
};

(我从Poco那里接受了"通知中心"这个术语,据我所知,它实现了两种方法).

我可以看到这种方法的一些优点; 目标创建订阅会更容易,因为他们不需要访问源.此外,不存在任何终身管理问题:与来源不同,通知中心将始终比目标更长,因此它们的目标总是取消订阅他们的析构函数而不用担心源是否仍然存在(这是我直接看到的主要因素)通讯).但是,我担心这种方法可能导致无法维护的代码,因为:

1. 各种各样的事件,可能完全不相互关联,将会发生在这一大陷阱中.

2. 实现通知中心最明显的方式是单独使用,因此很难跟踪修改订阅者列表的人和时间.

3. 事件在任何界面中都不可见,因此无法查看特定事件是否属于任何源.

由于这些缺点,我担心随着应用程序的增长,跟踪对象之间的连接将变得非常困难(例如,我正在想象试图理解为什么某些特定事件不会触发的问题).

我正在寻找有关"通知中心"方法的利弊的建议.它可维护吗？它适合各种应用吗？也许有办法改进实施？我所描述的两种方法之间的比较以及任何其他事件处理建议都是最受欢迎的.

Answer 1

这些方法是正交的。当特定对象之间交换事件时，应使用直接通信。通知中心方法只能用于广播事件，例如，当您想要处理给定类型的所有事件（无论其来源如何）时，或者当您想要将事件发送到您事先不知道的某些对象集时。

为了避免单例，请重用直接通信的代码，并以这种方式将通知中心对象订阅您要处理的所有事件。为了使事情易于管理，您可以在发出对象中执行此操作。

直接通信的生命周期相关问题通常通过要求订阅任何事件的每个类必须派生自特定基类来解决；在Boost.Signals中，这个类被称为trackable. 您的CreateDelegate函数的等效项将有关给定对象的订阅的信息存储在 内的数据成员中trackable。销毁时trackable，通过调用匹配函数取消所有订阅Unsubscribe。请注意，这不是线程安全的，因为trackable只有在派生类析构函数完成后才会调用 的析构函数 - 在一段时间内，部分销毁的对象仍然可以接收事件。