Designing an Event-Driven System in C++

Event-driven architecture is a fundamental paradigm in software design where components communicate through events rather than direct method calls. This article breaks down a professional implementation of an event system in C++ using two key files:

1.    event_system.h: Core event management classes.

2.    domain.cpp: Domain-specific events and usage examples.

The source codes can be found in github. Here I just want to highlight a few points that are good to me:

·         Modular Design: Components communicate without tight coupling.

·         Modern C++ Features: Templates, RAII, and lambda expressions.

·         Professional Patterns: Type erasure, publisher-subscriber.

·         Code Flow Visualization:

 [EventsManager]

   |--- stores --> [vector<unique_ptr<ISubscription>>]

                         |

                         |--- contains --> [SubscriptionWrapper<Event<int>>]

                         |                [SubscriptionWrapper<Event<string>>]

                         |                [SubscriptionWrapper<Event<CustomType>>]

                         |

                         |--- On destruction -->

                               [~ISubscription()] --> [~SubscriptionWrapper()] --> [~Event<T>::Subscription()]

 

The rest of this article is generated by deepseek:

Part 1: Core Concepts (event_system.h)

Part 2: Domain Implementation (domain.cpp)

Part 3: Type Erasure Explained: The Power of ISubscription with a Single Virtual Destructor

This design elegantly balances flexibility and type safety, demonstrating how minimal interfaces can enable powerful abstractions!

Part 1: Core Concepts (event_system.h)

1.1 The Event Template Class

Purpose: Create type-safe, reusable events that can carry data.

template <typename... Args>

class Event { /*...*/ };

• Template Parameters: Args... allow events to carry any data type.
• Key Features:
• subscribe(): Registers callbacks and returns a Subscription.
• trigger(): Broadcasts events to all subscribers.
• Automatic unsubscription via RAII.

1.2 The Subscription Class

Purpose: Manage callback lifetimes using RAII (Resource Acquisition Is Initialization.

class Subscription : public ISubscription { /*...*/ };

• RAII Principle: Automatically unsubscribes when destroyed.
• Move Semantics: Ensures safe ownership transfer (no copying allowed).

1.3 The EventsManager Class

Purpose: Centralize subscription management.

class EventsManager { /*...*/ };

• Type Erasure: Uses ISubscription and SubscriptionWrapper to store heterogeneous subscriptions.
• Lifetime Control: All subscriptions are destroyed when the manager is destroyed.

---

Part 2: Domain Implementation (domain.cpp)

2.1 Defining Event Types

struct TemperatureEvent { double value; };

struct DoorStatusEvent { bool isOpen; int sensorId; };

• Best Practice: Use simple structs for event data to ensure immutability.

2.2 Creating Event Instances

Event<TemperatureEvent> temperatureEvent;

Event<DoorStatusEvent> doorStatusEvent;

• Global vs. Local: These are global here for simplicity, but in larger projects, consider encapsulating them within classes.

2.3 Publisher-Subscriber Pattern

Example: Temperature Sensor (Publisher)

void update(double temp) {

    temperatureEvent.trigger(TemperatureEvent{temp});

}

Example: Climate Controller (Subscriber)

em.subscribe(temperatureEvent, [this](const TemperatureEvent& e) {

    adjustSystem(e.value);

});

---

Key Design Principles

1. Decoupling Components

• Publishers (e.g., TemperatureSensor) don’t know about subscribers (e.g., ClimateController).
• All communication happens through events.

2. RAII for Resource Management

• Subscriptions automatically clean up when they go out of scope:

~Subscription() { if(event_) event_->unsubscribe(id_); }

3. Type Safety

• Templates ensure compile-time checks:

// Compiler enforces correct event data types:

em.subscribe(temperatureEvent, [](const DoorStatusEvent& e) { /*...*/ }); // Error!

4. Scalability

• Add new events without modifying existing code:

Event<NetworkPacket> networkEvent;  // New event type

 

PART 3: Type Erasure Explained: The Power of ISubscription with a Single Virtual Destructor

What is Type Erasure?

Type erasure is a design pattern that allows you to work with heterogeneous types through a uniform interface, while hiding ("erasing") their specific type information. It’s like putting different objects into a black box—the outside code interacts with the box, not the objects inside.

Key Characteristics:

• Abstraction: Treat different types as if they were the same.
• Encapsulation: Hide type-specific details behind a common interface.
• Runtime Polymorphism: Resolve behavior at runtime (via virtual functions).

---

The ISubscription Class: Minimalist Type Erasure

In the event system code, ISubscription is the cornerstone of type erasure. Let’s break down its design:

Class Definition:

class ISubscription {

public:

    virtual ~ISubscription() = default;  // Single virtual destructor

};

Why This Works:

1. Common Interface:
   All subscription types (e.g., Event<int>::Subscription, Event<string>::Subscription) inherit from ISubscription. This allows them to be stored in a single container:

std::vector<std::unique_ptr<ISubscription>> subscriptions_;

2. Virtual Destructor:
• Ensures that when a unique_ptr<ISubscription> is destroyed, the correct derived class destructor is called.
• Triggers the destructor of the actual Event<T>::Subscription, which unsubscribes the callback.

---

How Type Erasure is Achieved

Step 1: Type-Specific Wrapper (SubscriptionWrapper)

For each event type Event<T>, we create a templated wrapper:

template <typename EventType>

struct SubscriptionWrapper : public ISubscription {

    typename EventType::Subscription sub;  // Concrete subscription

    SubscriptionWrapper(typename EventType::Subscription&& s)

        : sub(std::move(s)) {}

};

Step 2: Erase the Type

When storing subscriptions:

void EventsManager::subscribe(EventType& event, Callback&& cb) {

    auto sub = event.subscribe(std::forward<Callback>(cb));

    subscriptions_.emplace_back(

        std::make_unique<SubscriptionWrapper<EventType>>(std::move(sub))

    );

}

• The SubscriptionWrapper<EventType> is created for a specific event type (e.g., Event<int>).
• It is then upcast to ISubscription* and stored in the subscriptions_ vector.

Step 3: Type Recovery at Destruction

When subscriptions_ is cleared:

1. The unique_ptr<ISubscription> calls the virtual destructor of ISubscription.
2. Since SubscriptionWrapper inherits from ISubscription, its destructor is invoked.
3. This destroys the wrapped EventType::Subscription, which in turn unsubscribes the callback.

---

Why Only a Destructor?

The ISubscription interface needs only a virtual destructor because:

1. Minimal Contract: The only required operation is proper destruction.
2. No Other Operations: The EventsManager doesn’t need to interact with subscriptions—it just needs to manage their lifetimes.
3. Zero Overhead: No virtual function calls except during destruction.

---

Analogy: Library Book Returns

Imagine a library (EventsManager) that lends books (subscriptions) of various genres (event types). The librarian doesn’t care what genre a book is—they just need to know:

1. How to shelve it (store in a vector<ISubscription*>).
2. How to dispose of it (call the virtual destructor).

The genre-specific return process (unsubscribing) is handled automatically when the book is destroyed!

---

Key Takeaways

1. Type Erasure Pattern:
• Use a base class (ISubscription) to unify heterogeneous types.
• Leverage virtual destructors for type-specific cleanup.
2. Advantages:
• Decoupling: The EventsManager doesn’t know about specific event types.
• Scalability: Add new event types without modifying the manager.
• Resource Safety: RAII ensures no leaked subscriptions.
3. When to Use:
• Managing objects with heterogeneous types but common lifecycle needs.
• Hiding implementation details from client code.