Observer Pattern - Learning Module

Loading content...

0/246

Subject and Observers

The Two Halves of the Pattern

The Observer Pattern is fundamentally a two-party relationship: the Subject (the thing being watched) and the Observers (the things doing the watching). Understanding each party's responsibilities, interfaces, and constraints is essential for implementing the pattern correctly.

In the previous pages, we explored the problem and the publish-subscribe solution. Now we'll formalize the participants, examine their structure in detail, and explore advanced implementation considerations that separate production-ready code from textbook examples.

What You Will Learn

By the end of this page, you will have a complete understanding of Subject and Observer as formal participants: their responsibilities, their contractual obligations, the UML structure of the pattern, and how to implement both abstract and concrete versions. You'll also understand the lifecycle of observer relationships.

The Subject: The Observable Side

The Subject (also called Observable, Publisher, or Event Source) is the object that:

Owns the state that other objects are interested in
Maintains a list of observers who want to know about state changes
Notifies observers when its state changes

The Subject's responsibilities can be divided into state management (its primary business purpose) and observer management (its pattern-related duty):

Subject Responsibilities
Category	Responsibility	Typical Method	Frequency
Observer Mgmt	Accept new observer registrations	attach() / subscribe() / addObserver()	Once per observer
Observer Mgmt	Handle observer unregistration	detach() / unsubscribe() / removeObserver()	Once per observer
Observer Mgmt	Maintain observer collection	Internal Set/List field	Ongoing
Observer Mgmt	Notify all observers of changes	notify() / publish() / emit()	On every state change
State Mgmt	Manage its core state	setState() / setPrice() / etc.	Business-dependent
State Mgmt	Provide state access for observers	getState() / getPrice() / etc.	Per observer query

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
/**
 * Subject Interface (Abstract Observable)
 * 
 * This interface defines the observer management contract that
 * all Subjects must implement. It is typically a generic interface
 * where T represents the type of update data sent to observers.
 */
interface Subject<T = void> {
    /**
     * Registers an observer for future notifications.
     * 
     * Preconditions:
     * - observer is not null/undefined
     * - observer implements Observer<T> interface
     * 
     * Postconditions:
     * - observer will receive all future update(data) calls
     * - duplicate registration is either prevented or idempotent
     * 
     * @param observer The observer to register
     * @returns void, boolean, or unsubscribe function (implementation choice)
     */
    attach(observer: Observer<T>): void | boolean | (() => void);
    
    /**
     * Removes a previously registered observer.
     * 
     * Preconditions:
     * - observer was previously registered with attach()
     * 
     * Postconditions:
     * - observer will NOT receive future update(data) calls
     * - removing a non-registered observer is a no-op
     * 
     * @param observer The observer to remove
     */
    detach(observer: Observer<T>): void;
    
    /**
     * Notifies all registered observers of a state change.
     * 
     * Preconditions:
     * - Subject's state has changed (or notification is otherwise warranted)
     * 
     * Postconditions:
     * - Every attached observer has had update(data) called
     * - Order of notification follows implementation policy
     * - Exceptions in observers are handled per implementation policy
     */
    notify(): void;
}
 
/**
 * Common extension: Query observer status
 */
interface ExtendedSubject<T> extends Subject<T> {
    /**
     * Returns the number of currently attached observers.
     * Useful for monitoring and debugging.
     */
    getObserverCount(): number;
    
    /**
     * Checks if a specific observer is currently attached.
     */
    hasObserver(observer: Observer<T>): boolean;
    
    /**
     * Removes all observers. Use with caution.
     */
    clearObservers(): void;
}

Abstract vs Concrete Subject

In many implementations, the observer management logic is extracted into an abstract base class (like Java's Observable) that concrete subjects extend. This avoids repeating the attach/detach/notify logic in every subject. However, composition can achieve the same result without inheritance.

Implementing the Subject

Let's build a production-quality Subject step by step, addressing each design consideration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
/**
 * AbstractSubject - Reusable base class for observable objects
 * 
 * This class encapsulates all observer management logic so that
 * concrete subjects only need to focus on their business logic.
 */
abstract class AbstractSubject<T> implements ExtendedSubject<T> {
    // Using Set for O(1) add/remove and automatic deduplication
    private readonly observers: Set<Observer<T>> = new Set();
    
    // Optional: Track if we're currently notifying (for reentrancy detection)
    private isNotifying: boolean = false;
    
    // Pending operations during notification (if we want to defer changes)
    private pendingAttach: Set<Observer<T>> = new Set();
    private pendingDetach: Set<Observer<T>> = new Set();
    
    // ==========================================
    // Observer Management
    // ==========================================
    
    attach(observer: Observer<T>): () => void {
        // Validate input
        if (!observer) {
            throw new Error('Cannot attach null/undefined observer');
        }
        
        if (typeof observer.update !== 'function') {
            throw new Error('Observer must implement update() method');
        }
        
        // Handle registration during notification
        if (this.isNotifying) {
            // Defer the attachment until notification completes
            this.pendingAttach.add(observer);
            this.pendingDetach.delete(observer);
        } else {
            this.observers.add(observer);
        }
        
        // Return unsubscribe function for convenience
        return () => this.detach(observer);
    }
    
    detach(observer: Observer<T>): void {
        if (this.isNotifying) {
            // Defer the detachment until notification completes
            this.pendingDetach.add(observer);
            this.pendingAttach.delete(observer);
        } else {
            this.observers.delete(observer);
        }
    }
    
    notify(): void {
        // Create update data (subclasses define this)
        const data = this.getUpdateData();
        
        // Guard against reentrant notification
        const wasAlreadyNotifying = this.isNotifying;
        this.isNotifying = true;
        
        try {
            // Take a snapshot of observers to iterate
            // This protects against modification during iteration
            const observerSnapshot = Array.from(this.observers);
            
            for (const observer of observerSnapshot) {
                // Skip observers that were detached during this notification
                if (this.pendingDetach.has(observer)) {
                    continue;
                }
                
                try {
                    observer.update(data);
                } catch (error) {
                    // Isolate observer failures
                    this.handleObserverError(error as Error, observer);
                }
            }
        } finally {
            this.isNotifying = wasAlreadyNotifying;
            
            // Process pending operations if we're the outermost notify
            if (!wasAlreadyNotifying) {
                this.processPendingOperations();
            }
        }
    }
    
    private processPendingOperations(): void {
        // Apply pending detachments
        for (const observer of this.pendingDetach) {
            this.observers.delete(observer);
        }
        this.pendingDetach.clear();
        
        // Apply pending attachments
        for (const observer of this.pendingAttach) {
            this.observers.add(observer);
        }
        this.pendingAttach.clear();
    }
    
    // ==========================================
    // Extended Interface
    // ==========================================
    
    getObserverCount(): number {
        return this.observers.size;
    }
    
    hasObserver(observer: Observer<T>): boolean {
        return this.observers.has(observer);
    }
    
    clearObservers(): void {
        if (this.isNotifying) {
            // Mark all for removal
            for (const observer of this.observers) {
                this.pendingDetach.add(observer);
            }
        } else {
            this.observers.clear();
        }
    }
    
    // ==========================================
    // Template Methods (for subclasses)
    // ==========================================
    
    /**
     * Subclasses must implement this to provide update data.
     */
    protected abstract getUpdateData(): T;
    
    /**
     * Subclasses can override to customize error handling.
     */
    protected handleObserverError(error: Error, observer: Observer<T>): void {
        console.error(`Observer ${observer.constructor.name} threw:`, error);
    }
}

Key implementation decisions explained:

•Reentrancy protection — The isNotifying flag and snapshot iteration prevent modification of the observer collection during notification from causing skipped or duplicate notifications.
•Deferred operations — If an observer attaches or detaches during notification, we queue the change rather than immediately modifying the collection.
•Error isolation — Each observer call is wrapped in try-catch to prevent one failure from affecting others.
•Return unsubscribe function — This modern pattern simplifies cleanup, especially in functional codebases.
•Template method for update data — Subclasses define what data observers receive, keeping the base class generic.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
/**
 * StockPrice - A concrete Subject for stock price updates
 */
interface StockUpdate {
    symbol: string;
    currentPrice: number;
    previousPrice: number;
    change: number;
    changePercent: number;
    timestamp: Date;
    volume: number;
}
 
class StockPrice extends AbstractSubject<StockUpdate> {
    private symbol: string;
    private price: number = 0;
    private previousPrice: number = 0;
    private volume: number = 0;
    private lastUpdated: Date = new Date();
    
    constructor(symbol: string, initialPrice: number = 0) {
        super();
        this.symbol = symbol;
        this.price = initialPrice;
    }
    
    // Required by AbstractSubject
    protected getUpdateData(): StockUpdate {
        const change = this.price - this.previousPrice;
        const changePercent = this.previousPrice > 0 
            ? (change / this.previousPrice) * 100 
            : 0;
            
        return {
            symbol: this.symbol,
            currentPrice: this.price,
            previousPrice: this.previousPrice,
            change,
            changePercent,
            timestamp: this.lastUpdated,
            volume: this.volume,
        };
    }
    
    // Business methods
    setPrice(newPrice: number, volume: number = 0): void {
        if (newPrice < 0) {
            throw new Error('Price cannot be negative');
        }
        
        // Track previous for delta calculations
        this.previousPrice = this.price;
        this.price = newPrice;
        this.volume = volume;
        this.lastUpdated = new Date();
        
        // Notify observers of the change
        this.notify();
    }
    
    // Getters for observers who prefer pull model
    getSymbol(): string { return this.symbol; }
    getPrice(): number { return this.price; }
    getVolume(): number { return this.volume; }
}

The Observer: The Listening Side

The Observer (also called Subscriber, Listener, or Handler) is the object that:

Expresses interest in a Subject's state changes
Implements a callback that the Subject invokes on changes
Reacts appropriately to the update data it receives

Unlike the Subject, the Observer interface is remarkably simple—often just a single method:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
/**
 * Minimal Observer Interface
 * 
 * The classic, simplest form of Observer.
 */
interface Observer<T = void> {
    update(data: T): void;
}
 
/**
 * Extended Observer Interface
 * 
 * Additional lifecycle methods for more control.
 */
interface ExtendedObserver<T> extends Observer<T> {
    /**
     * Called when this observer is successfully attached to a subject.
     * Useful for initialization.
     */
    onAttach?(subject: Subject<T>): void;
    
    /**
     * Called when this observer is detached from a subject.
     * Useful for cleanup.
     */
    onDetach?(subject: Subject<T>): void;
    
    /**
     * Indicates whether this observer is still interested in updates.
     * Subject can check this before notifying.
     */
    isActive?(): boolean;
}
 
/**
 * Functional Observer
 * 
 * In functional programming, observers are often just functions.
 * This is equivalent to the interface but more concise.
 */
type FunctionalObserver<T> = (data: T) => void;
 
/**
 * Multiple Callback Observer (RxJS style)
 * 
 * Separate callbacks for different scenarios.
 */
interface RxObserver<T> {
    next?(value: T): void;      // Called on each value
    error?(err: Error): void;   // Called on error
    complete?(): void;          // Called when stream ends
}

Observer responsibilities:

Observer Responsibilities
Responsibility	Why It Matters	Common Mistake
Implement update()	Subject calls this; without it, pattern doesn't work	Forgetting to implement or implementing with wrong signature
React quickly	Slow reactions block other observers (in sync model)	Performing expensive operations in update()
Handle all data gracefully	Subject may send unexpected data	Assuming data has certain properties without checking
Manage own lifecycle	Observer should know when to attach/detach	Memory leaks from never detaching
Not modify shared data	Update data may be shared among observers	Mutating the data object, affecting other observers

Avoid Mutating Update Data

When multiple observers receive the same update object, one observer mutating that object affects all subsequent observers. Either design subjects to send immutable data, or make a defensive copy in each observer.

Implementing Observers

Observers come in many forms, each suited to different use cases. Let's examine several implementation patterns:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
/**
 * Class-based observers encapsulate both the update logic
 * and any state the observer needs to maintain.
 */
class TradingAlertObserver implements ExtendedObserver<StockUpdate> {
    private thresholds: Map<string, { low: number; high: number }>;
    private notificationService: NotificationService;
    private lastAlertTime: Map<string, number> = new Map();
    private alertCooldownMs: number = 60000; // Don't spam alerts
    
    constructor(notificationService: NotificationService) {
        this.notificationService = notificationService;
        this.thresholds = new Map();
    }
    
    setThreshold(symbol: string, low: number, high: number): void {
        this.thresholds.set(symbol, { low, high });
    }
    
    update(data: StockUpdate): void {
        const threshold = this.thresholds.get(data.symbol);
        if (!threshold) return; // Not tracking this symbol
        
        // Check cooldown to avoid spamming
        const lastAlert = this.lastAlertTime.get(data.symbol) || 0;
        if (Date.now() - lastAlert < this.alertCooldownMs) {
            return;
        }
        
        let alertMessage: string | null = null;
        
        if (data.currentPrice < threshold.low) {
            alertMessage = `⚠️ ${data.symbol} has dropped below $${threshold.low} (now $${data.currentPrice.toFixed(2)})`;
        } else if (data.currentPrice > threshold.high) {
            alertMessage = `🚀 ${data.symbol} has risen above $${threshold.high} (now $${data.currentPrice.toFixed(2)})`;
        }
        
        if (alertMessage) {
            this.notificationService.send(alertMessage);
            this.lastAlertTime.set(data.symbol, Date.now());
        }
    }
    
    // Lifecycle hooks
    onAttach(subject: Subject<StockUpdate>): void {
        console.log('TradingAlertObserver attached to subject');
    }
    
    onDetach(subject: Subject<StockUpdate>): void {
        console.log('TradingAlertObserver detached from subject');
        this.lastAlertTime.clear();
    }
    
    isActive(): boolean {
        return this.thresholds.size > 0;
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
/**
 * Functional observers are simple callbacks.
 * State is captured via closure.
 */
 
// Simple logging observer
const createLoggingObserver = (): Observer<StockUpdate> => ({
    update: (data) => {
        console.log(`[${data.timestamp.toISOString()}] ${data.symbol}: $${data.currentPrice.toFixed(2)} (${data.changePercent >= 0 ? '+' : ''}${data.changePercent.toFixed(2)}%)`);
    }
});
 
// Observer with captured state
const createMovingAverageObserver = (windowSize: number): Observer<StockUpdate> => {
    const priceHistory: number[] = [];
    
    return {
        update: (data) => {
            priceHistory.push(data.currentPrice);
            
            // Keep only last N prices
            if (priceHistory.length > windowSize) {
                priceHistory.shift();
            }
            
            const average = priceHistory.reduce((a, b) => a + b, 0) / priceHistory.length;
            console.log(`${data.symbol} ${windowSize}-period MA: $${average.toFixed(2)}`);
        }
    };
};
 
// Usage
const appleStock = new StockPrice('AAPL', 150);
appleStock.attach(createLoggingObserver());
appleStock.attach(createMovingAverageObserver(5));
appleStock.attach(createMovingAverageObserver(20));

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/**
 * For simple cases, observers can be defined inline.
 * This is common in UI frameworks and event handling.
 */
 
// If Subject accepts functional observers
appleStock.attach({
    update: (data) => {
        document.getElementById('price-display')!.textContent = 
            `$${data.currentPrice.toFixed(2)}`;
    }
});
 
// Even simpler if Subject accepts plain functions
appleStock.subscribe((data) => {
    document.getElementById('price-display')!.textContent = 
        `$${data.currentPrice.toFixed(2)}`;
});
 
// Common React pattern (where setState is the observer)
useEffect(() => {
    const unsubscribe = stockService.subscribe((update) => {
        setPrice(update.currentPrice);
    });
    
    return () => unsubscribe(); // Cleanup on unmount
}, []);

Choosing an Observer Pattern

Use class-based when observers need significant internal state, configuration, or lifecycle management. Use functional when the logic is stateless or state can be captured in a closure. Use inline for simple, one-off reactions.

The Formal UML Structure

The Observer Pattern has a formal structure documented in the Gang of Four book. Understanding this structure helps you recognize the pattern in existing code and communicate about it with other engineers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
┌──────────────────────────────────────────────────────────────────┐
│                    <<interface>>                                 │
│                       Subject                                    │
├──────────────────────────────────────────────────────────────────┤
│ + attach(observer: Observer): void                               │
│ + detach(observer: Observer): void                               │
│ + notify(): void                                                 │
└──────────────────────────┬───────────────────────────────────────┘
                           │ implements
                           ▼
┌──────────────────────────────────────────────────────────────────┐
│                    ConcreteSubject                               │
├──────────────────────────────────────────────────────────────────┤
│ - observers: Set<Observer>                                       │
│ - subjectState: StateType                                        │
├──────────────────────────────────────────────────────────────────┤
│ + attach(observer: Observer): void                               │
│ + detach(observer: Observer): void                               │
│ + notify(): void                                                 │
│ + getState(): StateType                                          │
│ + setState(state: StateType): void                               │
└──────────────────────────────────────────────────────────────────┘
                           │
                           │ notifies ─────────────────┐
                           │                           │
                           ▼                           │
┌──────────────────────────────────────────────────────────────────┐
│                    <<interface>>                                 │
│                       Observer                                   │
├──────────────────────────────────────────────────────────────────┤
│ + update(subject?: Subject): void                                │
└──────────────────────────┬───────────────────────────────────────┘
                           │ implements
     ┌─────────────────────┼─────────────────────┐
     ▼                     ▼                     ▼
┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│ConcreteObs A │    │ConcreteObs B │    │ConcreteObs C │
├──────────────┤    ├──────────────┤    ├──────────────┤
│- observerState│   │- observerState│   │- observerState│
├──────────────┤    ├──────────────┤    ├──────────────┤
│+ update()    │    │+ update()    │    │+ update()    │
└──────────────┘    └──────────────┘    └──────────────┘

Observer Pattern Participants
Participant	Role	Key Elements
Subject (interface)	Defines observer management contract	attach(), detach(), notify() methods
ConcreteSubject	Implements Subject, holds state of interest	Observer collection, state, state accessors
Observer (interface)	Defines update callback contract	update() method signature
ConcreteObserver	Implements Observer, reacts to updates	update() implementation, optional state

Relationship Types

The Subject aggregates Observers (it maintains a collection of them). ConcreteSubject implements Subject. ConcreteObservers implement Observer. There's no inheritance hierarchy between Subject and Observer—they're independent contracts connected only by the reference in the Subject's collection.

Observer Lifecycle Management

One of the most critical—and often overlooked—aspects of the Observer Pattern is lifecycle management. Observers must be properly attached when they need updates and properly detached when they're done. Failure to manage this correctly leads to memory leaks and ghost notifications.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// ❌ MEMORY LEAK: Observer never detached
 
class UserInterface {
    private stockPrice: StockPrice;
    private displayObserver: Observer<StockUpdate>;
    
    constructor(stockPrice: StockPrice) {
        this.stockPrice = stockPrice;
        
        // Create observer with reference to 'this'
        this.displayObserver = {
            update: (data) => {
                // This closure captures 'this' (the UserInterface)
                this.updateDisplay(data);
            }
        };
        
        // Attach observer
        this.stockPrice.attach(this.displayObserver);
    }
    
    private updateDisplay(data: StockUpdate): void {
        // Update UI
    }
    
    // No destroy/cleanup method exists!
    // When UserInterface is "discarded", the observer remains attached
    // The closure holds a reference to UserInterface, preventing garbage collection
}
 
// Usage pattern that causes leak:
function showTemporaryPanel(stockPrice: StockPrice) {
    const panel = new UserInterface(stockPrice);
    // Panel is shown, then user closes it
    // But panel is never garbage collected because:
    //   stockPrice.observers -> displayObserver -> panel
    // Each call to showTemporaryPanel leaks another panel!
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// ✅ CORRECT: Explicit cleanup with unsubscribe function
 
class UserInterface {
    private unsubscribe: (() => void) | null = null;
    
    constructor(stockPrice: StockPrice) {
        // attach() returns unsubscribe function
        this.unsubscribe = stockPrice.attach({
            update: (data) => this.updateDisplay(data)
        });
    }
    
    private updateDisplay(data: StockUpdate): void {
        // Update UI
    }
    
    destroy(): void {
        // Clean up observer subscription
        if (this.unsubscribe) {
            this.unsubscribe();
            this.unsubscribe = null;
        }
        
        // Other cleanup...
    }
}
 
// Usage with cleanup:
function showTemporaryPanel(stockPrice: StockPrice): () => void {
    const panel = new UserInterface(stockPrice);
    
    // Return cleanup function
    return () => {
        panel.destroy(); // Unsubscribes observer
        // Now panel can be garbage collected
    };
}
 
// Caller is responsible for cleanup:
const cleanup = showTemporaryPanel(appleStock);
// Later, when panel is no longer needed:
cleanup();

Observer Lifecycle Management Patterns
Pattern	When to Use	Example
Unsubscribe function	Modern functional code, React hooks	const unsub = subject.attach(obs); unsub();
Subscription object	When you need to track subscription state	const sub = subject.subscribe(...); sub.unsubscribe();
Dispose pattern	When observer has multiple cleanup tasks	observer.dispose() handles all cleanup
Automatic via WeakRef	When you want automatic cleanup on GC	Subject holds WeakRef to observers
Scope-based	When lifetime tied to a scope	Using a try-finally or component lifecycle

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
/**
 * Experimental: Using WeakRef for automatic observer cleanup.
 * Observer is automatically removed when garbage collected.
 * Note: Finalization timing is not guaranteed!
 */
class WeakSubject<T> {
    private observers: Set<WeakRef<Observer<T>>> = new Set();
    private registry: FinalizationRegistry<WeakRef<Observer<T>>>;
    
    constructor() {
        // When an observer is GC'd, remove its WeakRef from our set
        this.registry = new FinalizationRegistry((weakRef) => {
            this.observers.delete(weakRef);
        });
    }
    
    attach(observer: Observer<T>): void {
        const weakRef = new WeakRef(observer);
        this.observers.add(weakRef);
        this.registry.register(observer, weakRef);
    }
    
    notify(): void {
        const data = this.getUpdateData();
        
        for (const weakRef of this.observers) {
            const observer = weakRef.deref();
            if (observer) {
                observer.update(data);
            } else {
                // Observer was garbage collected, remove WeakRef
                this.observers.delete(weakRef);
            }
        }
    }
    
    protected getUpdateData(): T {
        throw new Error('Subclass must implement');
    }
}
 
// Note: WeakRef cleanup is non-deterministic and depends on GC timing.
// This approach is rarely used in practice because:
// 1. GC timing is unpredictable
// 2. You might still receive notifications after "disposing"
// 3. Explicit unsubscribe is more reliable

Never Rely on GC for Cleanup

While WeakRef is interesting academically, production code should always use explicit unsubscribe/dispose patterns. Garbage collection timing is not guaranteed, and leaving observer cleanup to GC can cause unpredictable behavior.

The Subject-Observer Relationship

Let's formalize the relationship between Subject and Observer with contracts that both sides must honor:

Subject Guarantees

•Notification Delivery — If you're attached, you'll receive all future update() calls until you detach.
•State Consistency — When update() is called, the subject is in a consistent state (no partial updates).
•No Duplicates — A single state change triggers at most one update() per observer.
•Error Isolation — Other observers' failures won't prevent your update() from being called.
•Detach Honored — Once detached, you will NOT receive future update() calls.

Observer Guarantees

•Implement update() — The method exists and is callable.
•Return Promptly — update() completes in reasonable time (don't block forever).
•Handle Data Safely — Won't mutate shared update data; handles null/unexpected cases.
•Manage Own Lifecycle — Will detach when no longer interested to avoid leaks.
•Tolerate Repeated Calls — Can handle update() being called multiple times, even rapidly.

No Guarantees About

•Notification Order — Unless explicitly documented, observers may be notified in any order.
•Immediate Notification — Subject may batch or defer notifications.
•Specific Thread — update() may be called from any thread (in concurrent systems).
•Notification Count — Subject may notify on every change or may coalesce rapid changes.
•Observer Completion Before Return — Subject may not wait for async observer work to complete.

Document Your Variant's Guarantees

If your implementation provides stronger guarantees (e.g., guaranteed order, guaranteed synchronous notification), document them clearly. Observers will rely on whatever behavior your implementation exhibits, so make the contract explicit.

Summary: Subject and Observers

We've now thoroughly examined both participants in the Observer Pattern—the Subject that publishes changes and the Observers that subscribe to them. Let's consolidate our understanding:

Key Takeaways

•The Subject has dual responsibilities — Managing its own state (business logic) AND managing observers (pattern mechanics). Abstract base classes can separate these concerns.
•The Observer interface is minimal — Usually just update(data). Extended variants add lifecycle hooks like onAttach/onDetach.
•Implementation patterns vary — Class-based observers for stateful reactions, functional observers for simple cases, inline for one-offs.
•Lifecycle management is critical — Always provide a way to detach observers. Unsubscribe functions are the modern best practice.
•Memory leaks lurk — Observers that capture external references prevent garbage collection. Explicit cleanup is essential.
•The relationship is contractual — Both parties make and honor promises. Document any guarantees your implementation provides beyond the basic contract.

What's next:

We've covered the pull model implicitly (observer queries subject) and the push model (subject sends data). In the next page, we'll examine these two models in depth—their tradeoffs, when to use each, and how to combine them effectively.

Page Complete

You now have a comprehensive understanding of Subject and Observer participants. You can implement production-ready subjects with reentrancy protection and error isolation, choose appropriate observer implementation patterns, and manage observer lifecycles correctly to avoid memory leaks.