You've been implementing this pattern since lesson 105. This lesson just gives it its name.

Lesson 105 taught you the event keyword — a controlled way for a class to announce "something happened" to whoever's interested. Lesson 106 built the full standard event pattern: custom EventArgs, a protected virtual OnXxx raiser, multiple subscribers reacting to one PriceChanged or OrderShipped event. Lesson 192 took that further with an EventAggregator, decoupling publishers and subscribers so neither knows the other exists.

Every single one of those lessons was teaching you a concrete C# implementation of a pattern with a formal name: the Observer Pattern — a Behavioral pattern from the design patterns lesson earlier in this Part. You already know how to use it. This lesson connects the dots: the classic GoF shape behind what you've been writing, and where else in .NET the exact same idea shows up.

By the end, you'll know the textbook Subject/Observer terminology, see precisely how C#'s event keyword implements it, and recognize IObservable<T>/IObserver<T> — the interfaces behind Rx.NET — as yet another concrete implementation of the same idea.

What Is It?

The Simple Explanation

The Observer Pattern defines a one-to-many relationship between objects: when one object's state changes, all its registered dependents are notified automatically. The object being watched doesn't need to know anything specific about who's watching — just that a list of watchers exists and should be told when something happens.

The Technical Definition — the Classic GoF Shape

The original GoF formulation names two roles:

Why Does It Exist? — The Problem It Solves

Without Observer, a class that needs to react to something happening elsewhere has two bad options: poll repeatedly to check "has it happened yet?", or the source object has to directly call every interested class by name — coupling it to every consumer it happens to know about today:

//  WITHOUT Observer — the order-shipping class directly calls
// every interested class by name, hard-coded, one by one
public sealed class OrderShippingService
{
    private readonly EmailNotifier _emailNotifier;
    private readonly AnalyticsLogger _analyticsLogger;
    private readonly InventorySync _inventorySync;

    public void MarkShipped(Order order)
    {
        // Every new "interested party" means editing THIS method directly —
        // OrderShippingService is now coupled to every consumer it knows about.
        _emailNotifier.SendShippedEmail(order);
        _analyticsLogger.LogShipment(order);
        _inventorySync.ReleaseReservedStock(order);
    }
}

Big Picture — Textbook Shape vs. C#'s event Keyword

public interface IObserver
{
    void Update(Order order);
}

public class OrderSubject
{
    private readonly List<IObserver> _observers = [];
    public void Attach(IObserver o) => _observers.Add(o);
    public void Notify(Order order)
    {
        foreach (var o in _observers)
            o.Update(order);
    }
}

public class OrderShippingService
{
    public event EventHandler<OrderShippedEventArgs>? OrderShipped;

    protected virtual void OnOrderShipped(OrderShippedEventArgs e) =>
        OrderShipped?.Invoke(this, e);

    public void MarkShipped(Order order) =>
        OnOrderShipped(new OrderShippedEventArgs(order.TrackingNumber));
}

These are the same pattern. _observers.Add(o) and OrderShipped += handler both register a watcher. foreach (var o in _observers) o.Update(order) and OrderShipped?.Invoke(this, e) both notify every registered watcher. C# just gives you the entire Subject bookkeeping — the list, the add/remove, the null-safe iteration — for free, via the compiler-generated multicast delegate behind every event field (lesson 097).

How It Works — Mapping event Onto Subject/Observer

Simple Example — Multiple Observers, One Subject

public sealed class OrderShippedEventArgs(string trackingNumber) : EventArgs
{
    public string TrackingNumber { get; } = trackingNumber;
}

public sealed class OrderShippingService   // ← the Subject
{
    public event EventHandler<OrderShippedEventArgs>? OrderShipped;

    private void OnOrderShipped(OrderShippedEventArgs e) => OrderShipped?.Invoke(this, e);

    public void MarkShipped(string trackingNumber) =>
        OnOrderShipped(new OrderShippedEventArgs(trackingNumber));
}

// ── Three independent Observers, none aware the others exist ──
var shipping = new OrderShippingService();

shipping.OrderShipped += (_, e) => Console.WriteLine($"[Email] Shipped: {e.TrackingNumber}");
shipping.OrderShipped += (_, e) => Console.WriteLine($"[Analytics] Logged: {e.TrackingNumber}");
shipping.OrderShipped += (_, e) => Console.WriteLine($"[Inventory] Released stock for: {e.TrackingNumber}");

shipping.MarkShipped("1Z999AA10123456784");
// All three handlers run — OrderShippingService never mentions Email, Analytics,
// or Inventory by name. That decoupling IS the Observer pattern working.

Code → Meaning → Result: Three completely unrelated Observers subscribe to one Subject. OrderShippingService knows nothing about email, analytics, or inventory — it only knows it has a list of delegates to invoke. Add a fourth Observer tomorrow, and OrderShippingService doesn't change at all.

Real-World Example — 192's Event Aggregator, Reframed

Lesson 192's EventAggregator is Observer taken one step further: instead of subscribing directly to one specific Subject instance, publishers and subscribers both depend only on IEventAggregator — a shared, decoupled "message bus" that plays Subject for the whole application:

// From 192 — the SAME Subject/Observer roles, generalized across the whole app:
public interface IEventAggregator
{
    void Publish<TEvent>(TEvent evt);              // Notify() — announce to all Observers
    void Subscribe<TEvent>(Action<TEvent> handler);  // Attach() — register an Observer
}
// AnalyticsModule and NotificationModule both Subscribe to the SAME event type,
// without ever referencing OrderFulfillmentService (the publisher) directly —
// and OrderFulfillmentService never references either subscriber directly.
// This is Observer, decoupled even further: publisher and subscriber depend
// only on the shared bus, not on each other.

Where a plain C# event field ties Observers directly to one specific Subject instance, an event aggregator generalizes the Subject role into a shared bus — but the underlying relationship (state change → notify a list of interested parties) is identical.

Analogy — A YouTube Channel

Under the Hood — IObservable<T> and IObserver<T>

The .NET base class library also defines Observer directly as a pair of generic interfaces — IObservable<T> and IObserver<T> — which are the foundation Reactive Extensions (Rx.NET) is built on:

This lesson won't teach Rx.NET's operators or reactive programming techniques — that's a large, separate topic outside this lesson's scope. The point here is purely vocabulary: recognize IObservable<T>/IObserver<T> as a third concrete .NET implementation of the exact same Subject/Observer relationship you already know from event, just with a richer, stream-oriented contract instead of a single notification.

Common Confusion

"If I use event, am I not really using the Observer pattern?"

You are — this is the single most important point of this lesson. GoF's Subject/Observer terminology predates C#'s event keyword by years; C# effectively baked the pattern directly into the language, with compiler-generated multicast delegate bookkeeping standing in for the hand-written List<IObserver>. Using event isn't "instead of" Observer — it IS Observer, expressed with first-class language support instead of a hand-rolled interface.

Observer vs. Strategy — don't mix these up

Both involve one class holding a reference to something interchangeable, but the shape is different. Strategy (241) is one-to-one: a context holds exactly one algorithm and calls it to get a result. Observer is one-to-many: a Subject holds a list of Observers and notifies all of them, expecting no return value back — it's a broadcast, not a request for an answer.

Common Mistakes

Mistake 1 — Forgetting to unsubscribe, and leaking memory (covered fully in 106)

A short-lived Observer subscribes to a long-lived Subject's event and never unsubscribes — the Subject's invocation list keeps a live reference to the Observer forever, preventing garbage collection. Always pair += with a corresponding -= when the Observer's lifetime is shorter than the Subject's — lesson 106 covers this in full depth.

Mistake 2 — Reaching for a hand-written Subject/IObserver interface pair when plain event already does the job

Writing a custom IObserver interface and a hand-rolled List<IObserver> Subject class in modern C#, duplicating exactly what event already gives you for free. Reach for C#'s built-in event keyword for ordinary in-process notifications — it's the idiomatic, battle-tested implementation of this pattern in C#, and reinventing it rarely earns its cost.

Mistake 3 — Assuming Observer guarantees ordering or error isolation between handlers

Relying on multiple subscribers to a single event running in a specific order, or assuming one handler throwing an exception won't stop the others from running — a plain multicast delegate invokes handlers sequentially in subscription order, and an unhandled exception in one handler will, by default, prevent later handlers in the same invocation from running. If handler independence or error isolation matters, that needs to be built deliberately (e.g., wrapping each handler call in its own try/catch, or using a dedicated event aggregator that isolates failures) — it isn't automatic just because you're "using Observer."

When Should I Use It?

• Whenever one or more parts of your application need to react to something happening in another part, without that other part needing to know who's reacting — UI updates, logging, analytics, cache invalidation, and notification fan-out are classic cases.
• Use plain C# event for straightforward, in-process, one-Subject notifications — it's the right default almost every time.
• Use an event aggregator (192) when publishers and subscribers shouldn't hold direct references to each other at all — often across module or feature boundaries.
• Reach for IObservable<T>/Rx.NET specifically when you need to compose, filter, or combine streams of notifications over time — genuinely out of scope for this introductory-level lesson, but worth knowing it exists for that purpose.

And when it's overkill: a direct method call is simpler and clearer than an event when there's exactly one fixed, always-present consumer that will never change — Observer's value comes specifically from not knowing (or needing to care) who's listening.

Mental Model

Key Takeaway

Check Your Understanding

You've connected C#'s event keyword to its formal GoF name. Let's confirm you can map the vocabulary both ways.

You already know how to use this pattern — now you know its name, its classic textbook shape, and where else in the .NET ecosystem the same idea shows up.

dotnetmadeeasy.com — Learn C# and .NET, the right way.