集中式事件调度的优点和缺点

我正在考虑在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:：信号、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. 事件在任何接口中都不可见，因此根本无法查看特定事件是否属于任何源。

由于这些缺点，我担心随着应用程序的发展，跟踪对象之间的连接会变得非常困难（例如，我在想象一些问题，试图理解为什么某个特定事件没有启动）。

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