编辑

Question

我想使用异步事件模式来解耦程序。我还想让基本事件类忽略实现，以最大程度地自由地通过事件传递我喜欢的任何东西。因此，在交换机内部使用static_cast似乎是一个简单且可能安全的解决方案：

enum class EventType
{
    None,
    EventA,
    EventB
};

class BaseEvent
{
    public:
        BaseEvent(EventType t = EventType::None) : type(t) { }
        virtual ~BaseEvent() {}
        auto get_type() { return type; }
    private:
        EventType type;

    // Oblivious and clean interface
};

class EventA : public BaseEvent
{
    public:
        EventA() : BaseEvent(EventType::EventA) { }

    // ... whatever I like
};
class EventB : public BaseEvent
{
    public:
        EventB() : BaseEvent(EventType::EventB) { }

    // ... whatever I like
};

void handle_event(BaseEvent* pe)
{
    switch (pe->get_type())
    {
        case EventType::EventA:
        {
            EventA* original_a = static_cast<EventA*>(pe);

            // In this case I know what is "pe" and what 
            // operations and data I can access and use.

            break;
        }
        case EventType::EventB:
        {
            EventB* original_b = static_cast<EventB*>(pe);

            //...

            break;
        }
    }
}

但是我也知道使用static_cast会带来一些风险，因为它会破坏类型检查。从我的理想主义角度来看，即使对于将来的可维护性，在这种情况下似乎也不是那么危险。只需检查该行

case EventType::EventA:

与以下行一致

EventA* original_a = static_cast<EventA*>(pe);

我知道，从理论上讲这似乎不是问题，但实际情况却截然不同。该解决方案可以用于大型项目吗？有没有更好的策略可以实现这种模式？

我知道我可以在基类中使用std :: variant的数组或向量，但是在派生事件的可能实现方面似乎存在很大局限性。我还可以使用映射来存储参数名称和它们的值，但是它看起来相当慢并且对内存不友好，并且同样限制了可能的参数类型。

或者，尽管也有开销，我也可以使用dynamic_cast，但也许它可以偿还增加可维护性的成本。

编辑

为简洁起见，我忘记提及有关该问题的一些重要细节：

必须将事件多态地放入一个容器中，所以我认为CRTP是不可行的。

上下文是基于代理的实时模拟（视频游戏），其中有一个主循环遍历事件。这些事件可以在每次迭代的任何地方触发。在接下来的迭代中，它们将由特定的处理程序处理。

std::queue<BaseEvent*> past_events;

int main()
{
    while (true)
    {
        while (!past_events.empty())
        {
            handle_event(past_events.front());

            //handle_event2(...)
            //handle_event3(...)
            //...

            past_events.pop();
        }

        // New events are fired...
    }
}

Answer 1

您的设计分析

乍一看，人们可能会认为这是次优的设计，因为您没有使用多态来让事件本身执行适当的操作，而不是让事件处理程序切换并强制转换。但是，在阅读您的论点时，会出现另一张图片：

您决定有意识地将用于处理事件的逻辑放在事件处理程序中。这使您可以将事件的处理与事件本身分离。换句话说，对于每个事件，不同的事件处理程序可能具有完全不同的行为（取决于上下文，事件接收器，应用程序等），就像每个Windows应用程序都有一些事件循环并在相同的事件中做出反应一样完全不同的方式。

因此，您故意选择不将行为放在事件中，因此不能在事件中使用多态。不知道具体情况，很难建议另一种方法。

后果

由于您已经定义了在基类中获取事件类型的逻辑，因此可以假定您对事件的类型非常了解，可以使用static_cast。但是...

风险编号1

但是，存在一种严重的风险，即有一天会创建一种新的事件类型，而该事件类型具有错误的事件类型（复制和粘贴，错字等）。这可能会导致UB。

缓解风险：

在运行时使用dynamic_cast拦截每个事件处理程序中的此类不一致之处。请注意，维护人员可能会忘记这一点，因此这是降低风险而非预防风险
或预见一个创建所有事件类型并在构建时进行dynamic_cast一致性检查的测试套件。

风险编号2

您可能具有事件的某些意外副本（复制构造函数或赋值），无论是否切片，都会意外覆盖事件的真实类型（例如if (*eventA=*eventB) /* ouch!! == */）。

缓解风险：从基本事件类中删除副本构造函数和分配，以防止发生此类事故。

通过switch和static_cast访问多态对象的运行时类型

编辑

1 个答案:

您的设计分析

后果

风险编号1

风险编号2