我正在考虑在 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 取了“通知中心”这个词，据我所知，它实现了这两种方法）。
我可以看到这种方法的一些优点；目标创建订阅会更容易，因为他们不需要访问源。此外，不会有任何生命周期管理问题：与源不同，通知中心总是比目标更长寿，因此它们的目标总是在其析构函数中取消订阅，而不用担心源是否仍然存在（这是我可以直接看到的一个主要问题沟通）。但是，我担心这种方法可能会导致无法维护的代码，因为：
各种各样的事件，可能彼此完全无关，都会进入这个大水槽。
实现通知中心最明显的方式是作为单例，因此很难跟踪谁以及何时修改了订阅者列表。
事件在任何界面中都不可见，因此根本无法查看特定事件是否属于任何源。
由于这些缺点，我担心随着应用程序的增长，跟踪对象之间的连接将变得非常困难（例如，我正在想象试图理解为什么某些特定事件不会触发的问题）。
我正在寻找有关“通知中心”方法优缺点的建议。是否可维护？它适合各种应用吗？也许有办法改进实施？我所描述的两种方法之间的比较，以及任何其他事件处理建议，都是非常受欢迎的。