Publisher-subscriber execution model in C Sharp (C#) - Deep Dive

Overview - Publisher-subscriber execution model

What is it?

The publisher-subscriber execution model is a way for parts of a program to talk to each other without being tightly connected. One part, called the publisher, sends messages or events. Other parts, called subscribers, listen and react when those messages arrive. This helps programs stay organized and flexible.

Why it matters

Without this model, programs would have parts directly calling each other, making changes hard and causing bugs. The publisher-subscriber model lets many parts work together smoothly, like a team passing notes instead of shouting. This makes programs easier to build, change, and fix.

Where it fits

Before learning this, you should understand basic programming concepts like functions and events. After this, you can explore advanced topics like event-driven programming, reactive programming, and designing scalable software systems.

Mental Model

Core Idea

The publisher-subscriber model lets senders broadcast messages that multiple receivers can listen to and act on independently.

Think of it like...

It's like a radio station (publisher) broadcasting music, and many people (subscribers) tuning in to listen whenever they want.

Publisher ──▶ [Event Bus] ──▶ Subscriber 1
                      │
                      ├──▶ Subscriber 2
                      │
                      └──▶ Subscriber 3

Build-Up - 7 Steps

1

Foundation

Understanding basic events and handlers

Concept: Learn what events are and how functions can respond to them.

In C#, an event is a way to signal that something happened. A handler is a function that runs when the event occurs. For example, a button click event calls a handler function to respond.

Result

You can write code that reacts when something happens, like a button press.

Knowing events and handlers is the foundation for understanding how publishers notify subscribers.

2

Foundation

Delegates as function pointers

Concept: Delegates let you store references to methods and call them later.

A delegate in C# is like a variable that holds a method. You can assign methods to delegates and invoke them. This allows flexible calling of different functions dynamically.

Result

You can pass methods around and call them without knowing exactly which method will run.

Delegates enable the publisher to call subscriber methods without knowing their details.

3

Intermediate

Creating a simple publisher-subscriber setup

🤔Before reading on: do you think a publisher can notify multiple subscribers at once or only one? Commit to your answer.

Concept: Combine events and delegates to let one publisher notify many subscribers.

Define an event in the publisher class using a delegate type. Subscribers add their handler methods to this event. When the publisher raises the event, all subscriber handlers run.

Result

Multiple subscribers respond when the publisher sends a message.

Understanding that events can have multiple subscribers is key to the model's power.

4

Intermediate

Subscribing and unsubscribing dynamically

🤔Before reading on: do you think subscribers can stop listening after subscribing? Commit to your answer.

Concept: Subscribers can add or remove their handlers at any time.

Subscribers use += to subscribe and -= to unsubscribe from events. This lets them start or stop listening based on program needs.

Result

Subscribers control when they receive notifications, improving flexibility.

Dynamic subscription management prevents unwanted reactions and resource waste.

5

Intermediate

Event arguments for detailed messages

Concept: Events can carry extra information to subscribers using event argument objects.

Define a class inheriting from EventArgs to hold data. The event handler receives this data when the event fires, letting subscribers know details about the event.

Result

Subscribers get context about what happened, enabling smarter responses.

Passing data with events makes communication richer and more useful.

6

Advanced

Thread safety in publisher-subscriber model

🤔Before reading on: do you think event invocation is always safe from multiple threads? Commit to your answer.

Concept: Events can be called from different threads, so synchronization is needed.

When multiple threads raise events or subscribe/unsubscribe, race conditions can occur. Use locking or thread-safe patterns to avoid errors.

Result

Your program avoids crashes or missed notifications in multi-threaded scenarios.

Knowing thread safety prevents subtle bugs in real-world applications.

7

Expert

Event aggregator pattern for decoupling

🤔Before reading on: do you think publishers and subscribers must know each other directly? Commit to your answer.

Concept: Use an event aggregator to centralize event management and reduce direct dependencies.

An event aggregator is a middleman that holds events. Publishers send messages to it, and subscribers listen to it. Neither needs to know about the other.

Result

Your system becomes more modular and easier to maintain or extend.

Centralizing event handling solves scaling and coupling problems in large systems.

Under the Hood

In C#, events are built on delegates, which are references to methods. When an event is raised, the delegate's invocation list calls each subscribed method in order. The runtime manages this list internally. Subscribing adds methods to the list, unsubscribing removes them. Thread safety is not automatic, so developers must ensure safe access when multiple threads interact with events.

Why designed this way?

The model was designed to separate concerns: publishers don't need to know who listens, and subscribers don't need to know who sends. Delegates provide a type-safe way to reference methods, and events restrict delegate access to prevent misuse. This design balances flexibility with safety and clarity.

Publisher ──▶ Event (delegate list) ──▶ Subscriber 1
                                │
                                ├──▶ Subscriber 2
                                │
                                └──▶ Subscriber 3

Subscribe: add method to delegate list
Unsubscribe: remove method from delegate list
Raise event: call all methods in delegate list

Myth Busters - 4 Common Misconceptions

Quick: Does unsubscribing from an event guarantee the handler will never be called again? Commit to yes or no.

Common Belief: Once you unsubscribe from an event, your handler will never be called again.

Reality: If the event is raised concurrently or just before unsubscribing, your handler might still be called one last time.

Why it matters: Assuming immediate unsubscription can cause unexpected behavior or bugs in multi-threaded programs.

Quick: Do you think events automatically handle errors in subscriber methods? Commit to yes or no.

Common Belief: If one subscriber throws an error, the event system catches it and continues notifying others.

Reality: An exception in one subscriber stops the event invocation, preventing other subscribers from running unless handled explicitly.

Why it matters: Not handling exceptions can cause partial notifications and hard-to-find bugs.

Quick: Can a publisher know which subscribers are listening to its events? Commit to yes or no.

Common Belief: Publishers can see and control their subscribers directly.

Reality: Publishers only know about the event delegate, not the subscribers themselves, keeping them decoupled.

Why it matters: Trying to manage subscribers from the publisher breaks the model's design and causes tight coupling.

Quick: Do you think the publisher-subscriber model always improves performance? Commit to yes or no.

Common Belief: Using this model always makes programs faster and more efficient.

Reality: It can add overhead and complexity, especially if many subscribers or events exist, or if thread safety is not handled well.

Why it matters: Blindly using this model without design can hurt performance and maintainability.

Expert Zone

1

Event invocation order is the order subscribers were added, but relying on this order is fragile and discouraged.

2

Weak references can be used for subscribers to avoid memory leaks when subscribers forget to unsubscribe.

3

Custom event accessors can control how subscriptions are added or removed, enabling advanced behaviors like filtering or logging.

When NOT to use

Avoid this model when you need strict synchronous processing or guaranteed delivery order. Alternatives include direct method calls for simple cases or message queues for guaranteed, durable messaging.

Production Patterns

In real systems, event aggregators or message buses centralize events. Dependency injection frameworks manage subscriptions. Logging and error handling wrappers protect event invocation. Weak event patterns prevent memory leaks in UI applications.

Connections

Observer pattern

The publisher-subscriber model is a practical implementation of the observer pattern.

Understanding the observer pattern helps grasp the design principles behind publisher-subscriber systems.

Reactive programming

Publisher-subscriber is a foundation for reactive programming, where data streams and events drive program flow.

Knowing this model aids in learning reactive frameworks that handle asynchronous data elegantly.

Broadcast communication in social networks

Both involve one sender sharing information to many receivers without direct connections.

Seeing this model in social networks helps appreciate its power in decoupling and scalability.

Common Pitfalls

#1 Forgetting to unsubscribe leads to memory leaks.

Wrong approach:

publisher.SomeEvent += subscriber.Handler; // subscribed but never unsubscribed

Correct approach:

publisher.SomeEvent += subscriber.Handler;
// later when no longer needed
publisher.SomeEvent -= subscriber.Handler;

Root cause:

Developers often overlook that event subscriptions keep objects alive, causing memory not to be freed.

#2 Not handling exceptions in subscriber methods.

Wrong approach:

void Handler(object sender, EventArgs e) { throw new Exception("Error"); }

Correct approach:

void Handler(object sender, EventArgs e) { try { /* work */ } catch { /* handle error */ } }

Root cause:

Assuming the event system manages errors leads to crashes or incomplete notifications.

#3 Raising events without checking for subscribers causes errors.

Wrong approach:

SomeEvent(this, EventArgs.Empty); // throws if no subscribers

Correct approach:

SomeEvent?.Invoke(this, EventArgs.Empty); // safe call

Root cause:

Not checking for null delegate causes runtime exceptions.

Key Takeaways

The publisher-subscriber model decouples senders and receivers, making programs flexible and easier to maintain.

Events and delegates in C# provide the building blocks for this model, allowing multiple subscribers to listen to one publisher.

Managing subscriptions carefully, including unsubscribing and handling threading, is crucial to avoid bugs and memory issues.

Advanced patterns like event aggregators help scale this model in large applications by centralizing event management.

Understanding this model opens doors to reactive programming and designing responsive, modular software.

Practice

1. In the publisher-subscriber model in C#, what is the main role of the subscriber?

easy

A. To send messages to multiple listeners

B. To register methods that respond to events from the publisher

C. To create new events for the publisher

D. To directly modify the publisher's data

Solution

1. Step 1: Understand the roles in the model

   The publisher sends messages or events, while the subscriber listens and reacts.

2. Step 2: Identify subscriber's responsibility

   Subscribers register their methods to handle events raised by the publisher.

3. Final Answer:

   To register methods that respond to events from the publisher -> Option B

4. Quick Check:

   Subscriber = method registration [OK]

Hint: Subscribers listen and react by registering methods [OK]

Common Mistakes:

• Confusing publisher and subscriber roles
• Thinking subscriber sends messages
• Assuming subscriber modifies publisher directly

2. Which of the following is the correct syntax to subscribe a method named OnDataReceived to an event DataReceived in C#?

easy

A. DataReceived += OnDataReceived;

B. DataReceived = OnDataReceived();

C. DataReceived -= OnDataReceived;

D. OnDataReceived += DataReceived;

Solution

1. Step 1: Recall event subscription syntax

   In C#, subscribing to an event uses the += operator with the method name (without parentheses).

2. Step 2: Match correct syntax

   DataReceived += OnDataReceived; correctly subscribes the method.

3. Final Answer:

   DataReceived += OnDataReceived; -> Option A

4. Quick Check:

   Subscribe event = += method [OK]

Hint: Use += to subscribe methods to events [OK]

Common Mistakes:

• Using = instead of +=
• Calling method with parentheses when subscribing
• Confusing subscription with unsubscription (-=)

3. Consider the following C# code snippet:

public class Publisher {
    public event Action Notify;
    public void Raise() {
        Notify?.Invoke();
    }
}

public class Subscriber {
    public void Respond() {
        Console.WriteLine("Event received");
    }
}

var pub = new Publisher();
var sub = new Subscriber();
pub.Notify += sub.Respond;
pub.Raise();

What will be the output when pub.Raise() is called?

medium

A. No output

B. NullReferenceException

C. Event received

D. Compile-time error

Solution

1. Step 1: Understand event subscription and invocation

   The subscriber's Respond method is subscribed to the Notify event, so it will be called when Raise() invokes Notify.

2. Step 2: Analyze output of Respond method

   Respond prints "Event received" to the console, so this text will appear.

3. Final Answer:

   Event received -> Option C

4. Quick Check:

   Subscribed method runs and prints message [OK]

Hint: Subscribed methods run on event invoke [OK]

Common Mistakes:

• Forgetting to subscribe the method
• Expecting no output if event is null
• Confusing event invocation syntax

4. The following code tries to unsubscribe a method from an event but causes a runtime error:

public class Publisher {
    public event Action Notify;
}

var pub = new Publisher();
pub.Notify -= () => Console.WriteLine("Hello");

What is the main issue causing the error?

medium

A. Lambda expressions cannot be used with events

B. Events cannot be unsubscribed in C#

C. The event Notify is not initialized

D. Cannot unsubscribe a lambda expression that was never subscribed

Solution

1. Step 1: Understand event unsubscription rules

   In C#, events start as null delegates. Unsubscribing (-=) from a null event throws NullReferenceException.

2. Step 2: Identify cause of runtime error

   No prior subscription means Notify is null, so pub.Notify -= lambda throws NullReferenceException. The lambda was never subscribed.

3. Final Answer:

   Cannot unsubscribe a lambda expression that was never subscribed -> Option D

4. Quick Check:

   Null event -= throws NullRef [OK]

Hint: Unsubscribe only delegates you subscribed before [OK]

Common Mistakes:

• Assuming unsubscribing any lambda works
• Thinking events cannot be unsubscribed
• Confusing null event invocation with unsubscription

5. You want to implement a publisher-subscriber system where multiple subscribers can register to receive messages, but some subscribers should only receive messages if a condition is true (e.g., message contains a keyword). Which approach best applies this conditional filtering in C#?

hard

A. Use event subscription with wrapper methods that check the condition before handling

B. Modify the publisher to send messages only to specific subscribers directly

C. Use multiple events for each condition and subscribe accordingly

D. Use a single event and let subscribers unsubscribe if condition is false

Solution

1. Step 1: Understand conditional filtering in subscriber model

   The publisher sends events to all subscribers; filtering is best done in subscriber methods.

2. Step 2: Apply wrapper methods for condition

   Subscribers can register methods that first check the condition and only proceed if true, keeping publisher simple.

3. Step 3: Evaluate other options

   Modifying publisher to target subscribers breaks decoupling; multiple events add complexity; unsubscribing dynamically is inefficient.

4. Final Answer:

   Use event subscription with wrapper methods that check the condition before handling -> Option A

5. Quick Check:

   Filter in subscriber methods for flexibility [OK]

Hint: Filter messages inside subscriber methods [OK]

Common Mistakes:

• Trying to filter inside publisher breaking decoupling
• Creating many events for each condition
• Unsubscribing subscribers dynamically instead of filtering