c++ - 集中式事件分发的优缺点

Question

我正在考虑在 C++ 应用程序中实现事件的不同方法。有人建议通过通知中心实现集中式事件分发。另一种方法是让事件的源和目标直接通信。但是，我对通知中心方法持保留意见。我将概述我所看到的这两种方法(我很可能对它们有一些误解，我以前从未实现过事件处理)。

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

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 signals/slots 和 .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 的析构函数仅在派生类析构函数完成后调用 - 有一段时间，部分销毁的对象仍然可以接收事件。