System Design (LLD)Mediator Pattern

Mediator Pattern: Centralizing Complex Interactions

LevelIntermediate

Duration60 mins

TopicMediator Pattern

3 / 4

Mediator vs Facade: Understanding the Distinction

The Pattern Confusion

Pattern confusion is one of the most common obstacles in design pattern education. The Mediator and Facade patterns are frequently conflated because they share a surface-level similarity: both involve a single object that coordinates or simplifies interaction with multiple other objects.

This superficial resemblance masks fundamental differences in intent, behavior, and appropriate use cases. Misapplying these patterns leads to designs that solve the wrong problem, creating maintenance burdens rather than alleviating them.

What You Will Learn

This page provides a rigorous comparison of Mediator and Facade. You'll understand their different intents, architectural structures, communication patterns, and when to apply each. By the end, you'll confidently distinguish between them and apply the right pattern for each situation.

The Core Distinction: Intent

Design patterns are defined primarily by their intent—the problem they solve. Understanding intent is more important than memorizing structural details, because intent guides correct application.

Pattern Intent Comparison
Pattern	Intent (GoF Definition)	Problem Solved
Mediator	Define an object that encapsulates how a set of objects interact	Complex, bidirectional many-to-many communication between peers
Facade	Provide a unified interface to a set of interfaces in a subsystem	Simplify access to a complex subsystem for external clients

Let's unpack what these intents really mean:

Mediator's intent is about interaction encapsulation. The objects being mediated are peers that need to collaborate. They have ongoing, bidirectional relationships. The mediator manages how they work together, enforcing coordination rules and eliminating direct dependencies between them.

Facade's intent is about interface simplification. The objects behind the facade are subsystem components that together provide some capability. External clients don't need to understand the subsystem's internal structure—they just want to accomplish tasks. The facade provides a simple entry point.

The Litmus Test

Ask yourself: Are the objects peers that need to coordinate their behavior with each other? → Use Mediator. Are the objects components of a subsystem that external clients need simplified access to? → Use Facade.

Structural Differences

While both patterns involve a central coordinating object, their internal structures differ significantly:

mediator-structure-comparison.ts
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
// ═══════════════════════════════════════════════════════════════════
// MEDIATOR STRUCTURE
// ═══════════════════════════════════════════════════════════════════
 
/**
 * Mediator Pattern Structure
 * 
 * Key characteristics:
 * 1. Colleagues know about the mediator (bidirectional reference)
 * 2. Mediator knows about all colleagues
 * 3. Colleagues communicate THROUGH mediator, not TO it for tasks
 * 4. Communication is bidirectional and ongoing
 */
 
interface ChatMediator {
    sendMessage(message: string, sender: ChatUser): void;
    addUser(user: ChatUser): void;
}
 
abstract class ChatUser {
    protected mediator: ChatMediator;
    protected name: string;
    
    constructor(name: string, mediator: ChatMediator) {
        this.name = name;
        this.mediator = mediator;
        this.mediator.addUser(this);  // Register with mediator
    }
    
    // Outbound: user sends message THROUGH mediator
    public send(message: string): void {
        console.log(`${this.name} sends: ${message}`);
        this.mediator.sendMessage(message, this);
    }
    
    // Inbound: user receives message FROM mediator
    public abstract receive(message: string, from: string): void;
}
 
class RegularUser extends ChatUser {
    receive(message: string, from: string): void {
        console.log(`${this.name} received from ${from}: ${message}`);
    }
}
 
class ChatRoom implements ChatMediator {
    private users: ChatUser[] = [];
    
    addUser(user: ChatUser): void {
        this.users.push(user);
    }
    
    // The mediator's job: coordinate message distribution
    sendMessage(message: string, sender: ChatUser): void {
        for (const user of this.users) {
            if (user !== sender) {
                user.receive(message, sender.name);
            }
        }
    }
}
 
// KEY OBSERVATION: 
// - Users don't know about each other
// - Users call mediator AND mediator calls users (bidirectional)
// - Mediator contains coordination LOGIC (who gets what messages)

facade-structure-comparison.ts
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
// ═══════════════════════════════════════════════════════════════════
// FACADE STRUCTURE
// ═══════════════════════════════════════════════════════════════════
 
/**
 * Facade Pattern Structure
 * 
 * Key characteristics:
 * 1. Subsystem components DON'T know about facade
 * 2. Facade knows about subsystem components
 * 3. Clients call facade TO accomplish tasks
 * 4. Communication is unidirectional (client → facade → subsystem)
 */
 
// Subsystem components - they exist independently of facade
class VideoDecoder {
    decode(filename: string): ArrayBuffer {
        console.log(`Decoding video: ${filename}`);
        return new ArrayBuffer(1024);
    }
}
 
class AudioDecoder {
    decode(filename: string): ArrayBuffer {
        console.log(`Decoding audio: ${filename}`);
        return new ArrayBuffer(512);
    }
}
 
class VideoRenderer {
    render(videoData: ArrayBuffer): void {
        console.log(`Rendering video frame`);
    }
}
 
class AudioPlayer {
    play(audioData: ArrayBuffer): void {
        console.log(`Playing audio`);
    }
}
 
class SubtitleLoader {
    load(filename: string): string[] {
        console.log(`Loading subtitles`);
        return ["Subtitle line 1", "Subtitle line 2"];
    }
}
 
/**
 * Facade provides simplified interface
 * 
 * Notice: 
 * - Subsystem classes have NO reference to facade
 * - Facade orchestrates but doesn't receive callbacks
 * - This is a one-way simplification layer
 */
class VideoPlayerFacade {
    private videoDecoder: VideoDecoder;
    private audioDecoder: AudioDecoder;
    private videoRenderer: VideoRenderer;
    private audioPlayer: AudioPlayer;
    private subtitleLoader: SubtitleLoader;
    
    constructor() {
        this.videoDecoder = new VideoDecoder();
        this.audioDecoder = new AudioDecoder();
        this.videoRenderer = new VideoRenderer();
        this.audioPlayer = new AudioPlayer();
        this.subtitleLoader = new SubtitleLoader();
    }
    
    /**
     * Simple interface for clients
     * Hides the complexity of coordinating multiple subsystem objects
     */
    public playVideo(filename: string, withSubtitles: boolean = false): void {
        console.log(`\n▶️ Playing: ${filename}`);
        
        // Facade orchestrates subsystem
        const videoData = this.videoDecoder.decode(filename);
        const audioData = this.audioDecoder.decode(filename);
        
        if (withSubtitles) {
            const subs = this.subtitleLoader.load(filename);
            console.log(`Subtitles loaded: ${subs.length} lines`);
        }
        
        this.videoRenderer.render(videoData);
        this.audioPlayer.play(audioData);
        
        console.log(`✅ Video playing\n`);
    }
}
 
// Client code - simple and clean
const player = new VideoPlayerFacade();
player.playVideo("movie.mp4", true);
 
// KEY OBSERVATION:
// - Subsystem components don't know facade exists
// - Facade calls subsystem, but subsystem never calls back
// - Facade simplifies INTERFACE, not behavior coordination

Key Structural Differences

•Reference direction: In Mediator, colleagues hold references TO the mediator. In Facade, only the facade holds references to subsystem components—they don't reference the facade.
•Communication direction: Mediator involves bidirectional communication (colleagues ↔ mediator). Facade involves unidirectional flow (client → facade → subsystem).
•Component awareness: Mediated colleagues know they're being mediated. Facade subsystem components are completely unaware of the facade's existence.
•Coordination vs. Delegation: Mediator coordinates peer behavior. Facade delegates to implement high-level operations.

Communication Flow Comparison

The communication patterns in Mediator and Facade are fundamentally different. Understanding these flows clarifies when each pattern applies.

In the Mediator pattern, communication flows in both directions between the mediator and its colleagues:

ColleagueA  ←→  Mediator  ←→  ColleagueB
                   ↕
              ColleagueC

Flow sequence:

ColleagueA has an event (e.g., user clicked a button)
ColleagueA notifies the Mediator: "Button was clicked"
Mediator processes the event and decides coordination needed
Mediator calls methods on ColleagueB and ColleagueC
ColleagueB and ColleagueC may generate new events, repeating the cycle

This is dialogue, not just a request. Colleagues actively participate in ongoing coordination.

In the Facade pattern, communication flows in one direction from client through facade to subsystem:

Client  →  Facade  →  SubsystemA
                   →  SubsystemB
                   →  SubsystemC

Flow sequence:

Client calls a simple method on Facade
Facade determines which subsystem components to invoke
Facade calls methods on subsystem components in appropriate order
Subsystem components return results to Facade
Facade may aggregate results and return to Client

This is delegation, not coordination. The facade acts as a simplified entry point to complex operations.

Communication Characteristics
Characteristic	Mediator	Facade
Direction	Bidirectional	Unidirectional
Initiator	Any colleague	External client only
Flow type	Event-driven dialogue	Request-response delegation
Ongoing?	Yes, continuous coordination	No, discrete requests
Callbacks	Common (mediator calls colleagues)	Rare (subsystem returns values)

Quick Check

If objects behind your 'coordinator' call back to it with events → Mediator. If they just return values and never initiate communication → Facade.

Use Case Comparison

Real-world examples illuminate the difference more clearly than abstract descriptions. Let's examine where each pattern naturally applies.

When to Use Mediator

•Chat rooms and messaging systems: Users (colleagues) send messages that must be distributed to other users. The chat room (mediator) coordinates who receives what.
•GUI dialog boxes: Form controls (colleagues) need to react to each other's changes. The dialog controller (mediator) coordinates validation, enabling/disabling, and state synchronization.
•Air traffic control: Aircraft (colleagues) need coordination for safe navigation. The control tower (mediator) manages separation, landing sequences, and collision avoidance.
•Multiplayer game lobbies: Players (colleagues) need to see each other's status, readiness, and settings. The lobby manager (mediator) synchronizes state across all players.
•Event orchestration systems: Multiple services (colleagues) need to coordinate complex business workflows. The orchestrator (mediator) manages the workflow state and triggers appropriate services.

When to Use Facade

•Video/audio encoding: Complex encoder libraries have many components (codec selection, bitrate control, filtering, muxing). A facade provides simple encode(input, format) method.
•Document generation: Creating PDFs involves fonts, layout, images, compression. A facade provides generateReport(data) without exposing PDF internals.
•E-commerce checkout: Payment processing involves validation, fraud detection, payment gateway, receipts. A facade provides processPayment(order) method.
•Cloud service SDKs: AWS, GCP, Azure have hundreds of services. Facades like 'Storage Service' simplify common operations across underlying complexity.
•Compiler front-ends: Lexing, parsing, AST construction, semantic analysis are complex. A facade provides compile(sourceCode) method.

The Key Difference in Use Cases

Notice that Mediator use cases involve ongoing, dynamic relationships between peers (users chat, controls react, aircraft navigate). Facade use cases involve one-time operations on subsystems (encode a video, generate a report, process a payment).

Same Scenario, Different Patterns

To truly understand the distinction, let's implement the same domain—a home automation system—using both patterns. This demonstrates how the choice depends on what problem you're solving.

home-automation-facade.ts
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
// ═══════════════════════════════════════════════════════════════════
// HOME AUTOMATION WITH FACADE
// Purpose: Simplify complex subsystem for external clients
// ═══════════════════════════════════════════════════════════════════
 
// Subsystem components (don't know about facade)
class LightingSystem {
    setLevel(room: string, level: number): void {
        console.log(`  💡 ${room} lights set to ${level}%`);
    }
}
 
class HVACSystem {
    setTemperature(temp: number): void {
        console.log(`  🌡️ Temperature set to ${temp}°F`);
    }
    
    setMode(mode: "heat" | "cool" | "auto"): void {
        console.log(`  🌡️ HVAC mode: ${mode}`);
    }
}
 
class SecuritySystem {
    arm(): void {
        console.log(`  🔒 Security armed`);
    }
    
    disarm(): void {
        console.log(`  🔓 Security disarmed`);
    }
}
 
class EntertainmentSystem {
    powerOn(): void {
        console.log(`  📺 Entertainment system on`);
    }
    
    powerOff(): void {
        console.log(`  📺 Entertainment system off`);
    }
}
 
class WindowBlinds {
    setPosition(position: number): void {
        console.log(`  🪟 Blinds set to ${position}%`);
    }
}
 
/**
 * Facade: Provides simple "scene" commands
 * 
 * Clients don't need to know about individual subsystems.
 * They just want to set a mood or scenario.
 */
class SmartHomeFacade {
    private lights: LightingSystem;
    private hvac: HVACSystem;
    private security: SecuritySystem;
    private entertainment: EntertainmentSystem;
    private blinds: WindowBlinds;
    
    constructor() {
        this.lights = new LightingSystem();
        this.hvac = new HVACSystem();
        this.security = new SecuritySystem();
        this.entertainment = new EntertainmentSystem();
        this.blinds = new WindowBlinds();
    }
    
    // Simple facade methods hide subsystem complexity
    
    public goodMorning(): void {
        console.log("\n☀️ Good Morning Scene:");
        this.blinds.setPosition(100);
        this.lights.setLevel("bedroom", 50);
        this.hvac.setTemperature(72);
        this.security.disarm();
    }
    
    public leaveHome(): void {
        console.log("\n🚪 Leaving Home Scene:");
        this.lights.setLevel("all", 0);
        this.entertainment.powerOff();
        this.hvac.setTemperature(65);
        this.security.arm();
        this.blinds.setPosition(0);
    }
    
    public movieNight(): void {
        console.log("\n🎬 Movie Night Scene:");
        this.blinds.setPosition(0);
        this.lights.setLevel("living room", 10);
        this.entertainment.powerOn();
        this.hvac.setTemperature(70);
    }
    
    public goodNight(): void {
        console.log("\n🌙 Good Night Scene:");
        this.lights.setLevel("all", 0);
        this.entertainment.powerOff();
        this.security.arm();
        this.hvac.setTemperature(68);
    }
}
 
// Usage: Simple, command-like interface
const home = new SmartHomeFacade();
home.goodMorning();
home.movieNight();
home.goodNight();
 
// Note: Subsystems never communicate with each other
// Facade is just orchestrating one-time scene setups

home-automation-mediator.ts
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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
// ═══════════════════════════════════════════════════════════════════
// HOME AUTOMATION WITH MEDIATOR
// Purpose: Coordinate ongoing interactions between smart devices
// ═══════════════════════════════════════════════════════════════════
 
// Smart devices that need to coordinate their behavior
 
interface SmartHomeMediator {
    notify(device: SmartDevice, event: string, data?: any): void;
}
 
abstract class SmartDevice {
    protected mediator: SmartHomeMediator;
    protected name: string;
    
    constructor(name: string, mediator: SmartHomeMediator) {
        this.name = name;
        this.mediator = mediator;
    }
    
    protected notifyChange(event: string, data?: any): void {
        this.mediator.notify(this, event, data);
    }
}
 
class MotionSensor extends SmartDevice {
    public detectMotion(room: string): void {
        console.log(`\n👁️ Motion detected in ${room}`);
        this.notifyChange("motion", { room });
    }
    
    public noMotion(room: string): void {
        console.log(`\n😴 No motion in ${room} for 10 minutes`);
        this.notifyChange("no-motion", { room });
    }
}
 
class SmartLight extends SmartDevice {
    private brightness: number = 0;
    
    public setBrightness(level: number): void {
        this.brightness = level;
        console.log(`  💡 ${this.name} set to ${level}%`);
    }
    
    public getBrightness(): number {
        return this.brightness;
    }
}
 
class SmartThermostat extends SmartDevice {
    private currentTemp: number = 70;
    private targetTemp: number = 70;
    
    public setTarget(temp: number): void {
        this.targetTemp = temp;
        console.log(`  🌡️ Target temperature: ${temp}°F`);
        this.notifyChange("target-changed", { temp });
    }
    
    public reportTemperature(temp: number): void {
        this.currentTemp = temp;
        console.log(`  📊 Current temperature: ${temp}°F`);
        this.notifyChange("temp-reading", { temp, target: this.targetTemp });
    }
}
 
class SmartBlinds extends SmartDevice {
    private position: number = 0;
    
    public setPosition(position: number): void {
        this.position = position;
        console.log(`  🪟 ${this.name} set to ${position}%`);
        this.notifyChange("blinds-changed", { position });
    }
    
    public getPosition(): number {
        return this.position;
    }
}
 
class DoorSensor extends SmartDevice {
    public doorOpened(): void {
        console.log(`\n🚪 Front door opened`);
        this.notifyChange("door-opened", {});
    }
    
    public doorClosed(): void {
        console.log(`\n🚪 Front door closed`);
        this.notifyChange("door-closed", {});
    }
}
 
/**
 * Mediator coordinates device interactions
 * 
 * Devices react to each other's events through the mediator.
 * This enables smart automation rules.
 */
class SmartHomeController implements SmartHomeMediator {
    private motionSensor: MotionSensor;
    private livingRoomLight: SmartLight;
    private bedroomLight: SmartLight;
    private thermostat: SmartThermostat;
    private blinds: SmartBlinds;
    private doorSensor: DoorSensor;
    
    public initialize(): void {
        this.motionSensor = new MotionSensor("Motion Sensor", this);
        this.livingRoomLight = new SmartLight("Living Room Light", this);
        this.bedroomLight = new SmartLight("Bedroom Light", this);
        this.thermostat = new SmartThermostat("Thermostat", this);
        this.blinds = new SmartBlinds("Smart Blinds", this);
        this.doorSensor = new DoorSensor("Door Sensor", this);
    }
    
    /**
     * Central coordination logic - devices interact through here
     */
    public notify(device: SmartDevice, event: string, data?: any): void {
        console.log(`  📬 Mediator received: ${event}`);
        
        // RULE: Motion detected → turn on lights in that room
        if (event === "motion") {
            const room = data.room;
            if (room === "living room") {
                this.livingRoomLight.setBrightness(80);
            } else if (room === "bedroom") {
                this.bedroomLight.setBrightness(50);
            }
        }
        
        // RULE: No motion → turn off lights after delay
        if (event === "no-motion") {
            const room = data.room;
            if (room === "living room") {
                this.livingRoomLight.setBrightness(0);
            } else if (room === "bedroom") {
                this.bedroomLight.setBrightness(0);
            }
        }
        
        // RULE: Temperature too high → open blinds to cool
        if (event === "temp-reading") {
            if (data.temp > data.target + 5) {
                console.log(`  🔥 Too hot! Opening blinds to cool down.`);
                this.blinds.setPosition(0);  // Close blinds to block sun
            }
        }
        
        // RULE: Door opened → turn on entry lights
        if (event === "door-opened") {
            this.livingRoomLight.setBrightness(100);
        }
        
        // RULE: Blinds closed → may need artificial light
        if (event === "blinds-changed" && data.position === 0) {
            if (this.livingRoomLight.getBrightness() > 0) {
                // Boost light since natural light reduced
                console.log(`  💡 Boosting lights due to closed blinds`);
                this.livingRoomLight.setBrightness(
                    Math.min(100, this.livingRoomLight.getBrightness() + 20)
                );
            }
        }
    }
    
    // Accessors for simulation
    public getDevices() {
        return {
            motionSensor: this.motionSensor,
            thermostat: this.thermostat,
            doorSensor: this.doorSensor,
            blinds: this.blinds,
        };
    }
}
 
// Usage: Ongoing device coordination
const controller = new SmartHomeController();
controller.initialize();
 
const { motionSensor, thermostat, doorSensor } = controller.getDevices();
 
// Simulate real-time device events
motionSensor.detectMotion("living room");   // → lights turn on
thermostat.reportTemperature(82);           // → blinds close → lights boost
doorSensor.doorOpened();                    // → entry lights on
motionSensor.noMotion("living room");       // → lights turn off

The critical difference:

The Facade provides simple commands (movieNight(), goodMorning()) that orchestrate subsystems for one-time operations. Subsystems don't interact with each other.
The Mediator enables ongoing device interaction. When motion is detected, lights respond. When temperature changes, blinds adjust. Devices are peers in an ongoing coordination relationship.

Hybrid Scenarios: Using Both Patterns

In complex systems, you might need both patterns working together. This isn't pattern abuse—it's appropriate separation of concerns.

hybrid-example.ts
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
// ═══════════════════════════════════════════════════════════════════
// HYBRID: Facade + Mediator in Smart Home
// ═══════════════════════════════════════════════════════════════════
 
/**
 * Scenario: Smart home has both:
 * 1. Simple scene commands for users (Facade use case)
 * 2. Ongoing device coordination (Mediator use case)
 * 
 * Solution: Facade provides user interface, Mediator handles device coordination
 */
 
// The Mediator handles ongoing device interactions (as before)
class DeviceCoordinator implements SmartHomeMediator {
    // ... device coordination logic ...
    notify(device: SmartDevice, event: string, data?: any): void {
        // Coordinate device interactions
    }
}
 
// The Facade provides simple user commands
// It can ALSO trigger mediator-coordinated behaviors
class SmartHomeUserInterface {
    private deviceCoordinator: DeviceCoordinator;
    
    constructor(coordinator: DeviceCoordinator) {
        this.deviceCoordinator = coordinator;
    }
    
    // Facade methods for simple user commands
    public activateMovieMode(): void {
        console.log("\n🎬 Activating Movie Mode...");
        
        // Some actions are simple facade orchestration
        // (subsystems don't need to coordinate)
        this.deviceCoordinator.setLights("living room", 10);
        this.deviceCoordinator.closeBlinds();
        this.deviceCoordinator.powerOnTV();
        
        // But we also switch the mediator to "movie mode"
        // which affects ongoing coordination rules
        this.deviceCoordinator.setMode("movie");
        // Now motion sensors won't turn lights on high, etc.
    }
    
    public activateAwayMode(): void {
        console.log("\n🚪 Activating Away Mode...");
        
        // Set everything to away state
        this.deviceCoordinator.setAllLights(0);
        this.deviceCoordinator.armSecurity();
        
        // Switch coordination mode
        this.deviceCoordinator.setMode("away");
        // Now motion triggers security alerts instead of lights
    }
}
 
// Usage:
// - User interacts with Facade (simple commands)
// - Devices interact through Mediator (ongoing coordination)
// - Facade can influence Mediator's behavior (change modes)

Hybrid Pattern Responsibilities
Concern	Pattern Used	Responsibility
User commands	Facade	Simple scene activation, mode switching
Device coordination	Mediator	Ongoing interaction rules, event handling
External API	Facade	Hide internal complexity from apps/voice assistants
Automation rules	Mediator	Manage complex multi-device behaviors

Design Principle

Don't be afraid to use multiple patterns in the same system. The key is using each pattern for its intended purpose. Facades simplify access; Mediators coordinate behavior. When you need both, implement both.

Decision Framework: Which Pattern to Use

Use this decision framework when you're unsure which pattern applies:

Ask These Questions

•Do the objects know about the coordinator? → If they hold a reference and call it: likely Mediator. If they're completely unaware: likely Facade.
•Is communication bidirectional? → If coordinator calls back into objects: likely Mediator. If it only aggregates/delegates: likely Facade.
•Are the objects peers or subsystem components? → Peers that collaborate: Mediator. Components that together provide a capability: Facade.
•Is coordination ongoing or one-time? → Ongoing dynamic behavior: Mediator. Discrete operations: Facade.
•What's the primary goal? → Eliminate coupling between objects: Mediator. Simplify interface for external clients: Facade.

Pattern Selection Quick Reference
Indicator	Choose Mediator	Choose Facade
Object-coordinator relationship	Bidirectional	Unidirectional (coordinator → objects)
Objects aware of coordinator	Yes	No
Primary problem	Object coupling	Interface complexity
Interaction duration	Ongoing	Per-request
Typical examples	Chat rooms, dialogs, game entities	Libraries, SDKs, complex subsystems

Common Mistake

Don't choose based on superficial structure. A class that 'coordinates' multiple objects could be either pattern. Always analyze the communication flow and intent.

Summary: Mediator vs Facade

We've thoroughly compared the Mediator and Facade patterns. Let's consolidate the key distinctions:

Key Takeaways

•Mediator encapsulates behavior; Facade simplifies interface — These are fundamentally different intents solving different problems
•Mediator involves bidirectional communication — Colleagues notify the mediator, and the mediator calls back into colleagues
•Facade involves unidirectional delegation — Clients call facade, facade orchestrates subsystem, subsystems return results
•Mediated objects know they're mediated — They hold mediator references and actively participate
•Facade subsystems are unaware — They're just components being used; they don't reference the facade
•Both patterns can coexist — Use Facade for external simplification and Mediator for internal coordination

What's next:

With the Mediator vs Facade distinction clear, the final page explores real-world use cases of the Mediator Pattern. We'll examine implementations in chat systems, event-driven architectures, and UI frameworks—showing how the pattern scales from simple dialogs to enterprise systems.

Page Complete

You now understand the critical distinction between Mediator and Facade patterns. Mediator coordinates peer behavior through bidirectional communication; Facade simplifies subsystem access through unidirectional delegation. Use the decision framework to choose correctly.

3 / 4

Loading learning content...

System Design (LLD)Mediator Pattern

Mediator Pattern: Centralizing Complex Interactions

LevelIntermediate

Duration60 mins

TopicMediator Pattern

3 / 4

Mediator vs Facade: Understanding the Distinction

The Pattern Confusion

What You Will Learn

The Core Distinction: Intent

Pattern Intent Comparison
Pattern	Intent (GoF Definition)	Problem Solved
Mediator	Define an object that encapsulates how a set of objects interact	Complex, bidirectional many-to-many communication between peers
Facade	Provide a unified interface to a set of interfaces in a subsystem	Simplify access to a complex subsystem for external clients

Let's unpack what these intents really mean:

The Litmus Test

Structural Differences

While both patterns involve a central coordinating object, their internal structures differ significantly:

mediator-structure-comparison.ts
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
// ═══════════════════════════════════════════════════════════════════
// MEDIATOR STRUCTURE
// ═══════════════════════════════════════════════════════════════════
 
/**
 * Mediator Pattern Structure
 * 
 * Key characteristics:
 * 1. Colleagues know about the mediator (bidirectional reference)
 * 2. Mediator knows about all colleagues
 * 3. Colleagues communicate THROUGH mediator, not TO it for tasks
 * 4. Communication is bidirectional and ongoing
 */
 
interface ChatMediator {
    sendMessage(message: string, sender: ChatUser): void;
    addUser(user: ChatUser): void;
}
 
abstract class ChatUser {
    protected mediator: ChatMediator;
    protected name: string;
    
    constructor(name: string, mediator: ChatMediator) {
        this.name = name;
        this.mediator = mediator;
        this.mediator.addUser(this);  // Register with mediator
    }
    
    // Outbound: user sends message THROUGH mediator
    public send(message: string): void {
        console.log(`${this.name} sends: ${message}`);
        this.mediator.sendMessage(message, this);
    }
    
    // Inbound: user receives message FROM mediator
    public abstract receive(message: string, from: string): void;
}
 
class RegularUser extends ChatUser {
    receive(message: string, from: string): void {
        console.log(`${this.name} received from ${from}: ${message}`);
    }
}
 
class ChatRoom implements ChatMediator {
    private users: ChatUser[] = [];
    
    addUser(user: ChatUser): void {
        this.users.push(user);
    }
    
    // The mediator's job: coordinate message distribution
    sendMessage(message: string, sender: ChatUser): void {
        for (const user of this.users) {
            if (user !== sender) {
                user.receive(message, sender.name);
            }
        }
    }
}
 
// KEY OBSERVATION: 
// - Users don't know about each other
// - Users call mediator AND mediator calls users (bidirectional)
// - Mediator contains coordination LOGIC (who gets what messages)

facade-structure-comparison.ts
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
// ═══════════════════════════════════════════════════════════════════
// FACADE STRUCTURE
// ═══════════════════════════════════════════════════════════════════
 
/**
 * Facade Pattern Structure
 * 
 * Key characteristics:
 * 1. Subsystem components DON'T know about facade
 * 2. Facade knows about subsystem components
 * 3. Clients call facade TO accomplish tasks
 * 4. Communication is unidirectional (client → facade → subsystem)
 */
 
// Subsystem components - they exist independently of facade
class VideoDecoder {
    decode(filename: string): ArrayBuffer {
        console.log(`Decoding video: ${filename}`);
        return new ArrayBuffer(1024);
    }
}
 
class AudioDecoder {
    decode(filename: string): ArrayBuffer {
        console.log(`Decoding audio: ${filename}`);
        return new ArrayBuffer(512);
    }
}
 
class VideoRenderer {
    render(videoData: ArrayBuffer): void {
        console.log(`Rendering video frame`);
    }
}
 
class AudioPlayer {
    play(audioData: ArrayBuffer): void {
        console.log(`Playing audio`);
    }
}
 
class SubtitleLoader {
    load(filename: string): string[] {
        console.log(`Loading subtitles`);
        return ["Subtitle line 1", "Subtitle line 2"];
    }
}
 
/**
 * Facade provides simplified interface
 * 
 * Notice: 
 * - Subsystem classes have NO reference to facade
 * - Facade orchestrates but doesn't receive callbacks
 * - This is a one-way simplification layer
 */
class VideoPlayerFacade {
    private videoDecoder: VideoDecoder;
    private audioDecoder: AudioDecoder;
    private videoRenderer: VideoRenderer;
    private audioPlayer: AudioPlayer;
    private subtitleLoader: SubtitleLoader;
    
    constructor() {
        this.videoDecoder = new VideoDecoder();
        this.audioDecoder = new AudioDecoder();
        this.videoRenderer = new VideoRenderer();
        this.audioPlayer = new AudioPlayer();
        this.subtitleLoader = new SubtitleLoader();
    }
    
    /**
     * Simple interface for clients
     * Hides the complexity of coordinating multiple subsystem objects
     */
    public playVideo(filename: string, withSubtitles: boolean = false): void {
        console.log(`\n▶️ Playing: ${filename}`);
        
        // Facade orchestrates subsystem
        const videoData = this.videoDecoder.decode(filename);
        const audioData = this.audioDecoder.decode(filename);
        
        if (withSubtitles) {
            const subs = this.subtitleLoader.load(filename);
            console.log(`Subtitles loaded: ${subs.length} lines`);
        }
        
        this.videoRenderer.render(videoData);
        this.audioPlayer.play(audioData);
        
        console.log(`✅ Video playing\n`);
    }
}
 
// Client code - simple and clean
const player = new VideoPlayerFacade();
player.playVideo("movie.mp4", true);
 
// KEY OBSERVATION:
// - Subsystem components don't know facade exists
// - Facade calls subsystem, but subsystem never calls back
// - Facade simplifies INTERFACE, not behavior coordination

Key Structural Differences

•Reference direction: In Mediator, colleagues hold references TO the mediator. In Facade, only the facade holds references to subsystem components—they don't reference the facade.
•Communication direction: Mediator involves bidirectional communication (colleagues ↔ mediator). Facade involves unidirectional flow (client → facade → subsystem).
•Component awareness: Mediated colleagues know they're being mediated. Facade subsystem components are completely unaware of the facade's existence.
•Coordination vs. Delegation: Mediator coordinates peer behavior. Facade delegates to implement high-level operations.

Communication Flow Comparison

The communication patterns in Mediator and Facade are fundamentally different. Understanding these flows clarifies when each pattern applies.

In the Mediator pattern, communication flows in both directions between the mediator and its colleagues:

ColleagueA  ←→  Mediator  ←→  ColleagueB
                   ↕
              ColleagueC

Flow sequence:

ColleagueA has an event (e.g., user clicked a button)
ColleagueA notifies the Mediator: "Button was clicked"
Mediator processes the event and decides coordination needed
Mediator calls methods on ColleagueB and ColleagueC
ColleagueB and ColleagueC may generate new events, repeating the cycle

This is dialogue, not just a request. Colleagues actively participate in ongoing coordination.

In the Facade pattern, communication flows in one direction from client through facade to subsystem:

Client  →  Facade  →  SubsystemA
                   →  SubsystemB
                   →  SubsystemC

Flow sequence:

Client calls a simple method on Facade
Facade determines which subsystem components to invoke
Facade calls methods on subsystem components in appropriate order
Subsystem components return results to Facade
Facade may aggregate results and return to Client

This is delegation, not coordination. The facade acts as a simplified entry point to complex operations.

Communication Characteristics
Characteristic	Mediator	Facade
Direction	Bidirectional	Unidirectional
Initiator	Any colleague	External client only
Flow type	Event-driven dialogue	Request-response delegation
Ongoing?	Yes, continuous coordination	No, discrete requests
Callbacks	Common (mediator calls colleagues)	Rare (subsystem returns values)

Quick Check

If objects behind your 'coordinator' call back to it with events → Mediator. If they just return values and never initiate communication → Facade.

Use Case Comparison

Real-world examples illuminate the difference more clearly than abstract descriptions. Let's examine where each pattern naturally applies.

When to Use Mediator

•Chat rooms and messaging systems: Users (colleagues) send messages that must be distributed to other users. The chat room (mediator) coordinates who receives what.
•GUI dialog boxes: Form controls (colleagues) need to react to each other's changes. The dialog controller (mediator) coordinates validation, enabling/disabling, and state synchronization.
•Air traffic control: Aircraft (colleagues) need coordination for safe navigation. The control tower (mediator) manages separation, landing sequences, and collision avoidance.
•Multiplayer game lobbies: Players (colleagues) need to see each other's status, readiness, and settings. The lobby manager (mediator) synchronizes state across all players.
•Event orchestration systems: Multiple services (colleagues) need to coordinate complex business workflows. The orchestrator (mediator) manages the workflow state and triggers appropriate services.

When to Use Facade

•Video/audio encoding: Complex encoder libraries have many components (codec selection, bitrate control, filtering, muxing). A facade provides simple encode(input, format) method.
•Document generation: Creating PDFs involves fonts, layout, images, compression. A facade provides generateReport(data) without exposing PDF internals.
•E-commerce checkout: Payment processing involves validation, fraud detection, payment gateway, receipts. A facade provides processPayment(order) method.
•Cloud service SDKs: AWS, GCP, Azure have hundreds of services. Facades like 'Storage Service' simplify common operations across underlying complexity.
•Compiler front-ends: Lexing, parsing, AST construction, semantic analysis are complex. A facade provides compile(sourceCode) method.

The Key Difference in Use Cases

Same Scenario, Different Patterns

To truly understand the distinction, let's implement the same domain—a home automation system—using both patterns. This demonstrates how the choice depends on what problem you're solving.

home-automation-facade.ts
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
// ═══════════════════════════════════════════════════════════════════
// HOME AUTOMATION WITH FACADE
// Purpose: Simplify complex subsystem for external clients
// ═══════════════════════════════════════════════════════════════════
 
// Subsystem components (don't know about facade)
class LightingSystem {
    setLevel(room: string, level: number): void {
        console.log(`  💡 ${room} lights set to ${level}%`);
    }
}
 
class HVACSystem {
    setTemperature(temp: number): void {
        console.log(`  🌡️ Temperature set to ${temp}°F`);
    }
    
    setMode(mode: "heat" | "cool" | "auto"): void {
        console.log(`  🌡️ HVAC mode: ${mode}`);
    }
}
 
class SecuritySystem {
    arm(): void {
        console.log(`  🔒 Security armed`);
    }
    
    disarm(): void {
        console.log(`  🔓 Security disarmed`);
    }
}
 
class EntertainmentSystem {
    powerOn(): void {
        console.log(`  📺 Entertainment system on`);
    }
    
    powerOff(): void {
        console.log(`  📺 Entertainment system off`);
    }
}
 
class WindowBlinds {
    setPosition(position: number): void {
        console.log(`  🪟 Blinds set to ${position}%`);
    }
}
 
/**
 * Facade: Provides simple "scene" commands
 * 
 * Clients don't need to know about individual subsystems.
 * They just want to set a mood or scenario.
 */
class SmartHomeFacade {
    private lights: LightingSystem;
    private hvac: HVACSystem;
    private security: SecuritySystem;
    private entertainment: EntertainmentSystem;
    private blinds: WindowBlinds;
    
    constructor() {
        this.lights = new LightingSystem();
        this.hvac = new HVACSystem();
        this.security = new SecuritySystem();
        this.entertainment = new EntertainmentSystem();
        this.blinds = new WindowBlinds();
    }
    
    // Simple facade methods hide subsystem complexity
    
    public goodMorning(): void {
        console.log("\n☀️ Good Morning Scene:");
        this.blinds.setPosition(100);
        this.lights.setLevel("bedroom", 50);
        this.hvac.setTemperature(72);
        this.security.disarm();
    }
    
    public leaveHome(): void {
        console.log("\n🚪 Leaving Home Scene:");
        this.lights.setLevel("all", 0);
        this.entertainment.powerOff();
        this.hvac.setTemperature(65);
        this.security.arm();
        this.blinds.setPosition(0);
    }
    
    public movieNight(): void {
        console.log("\n🎬 Movie Night Scene:");
        this.blinds.setPosition(0);
        this.lights.setLevel("living room", 10);
        this.entertainment.powerOn();
        this.hvac.setTemperature(70);
    }
    
    public goodNight(): void {
        console.log("\n🌙 Good Night Scene:");
        this.lights.setLevel("all", 0);
        this.entertainment.powerOff();
        this.security.arm();
        this.hvac.setTemperature(68);
    }
}
 
// Usage: Simple, command-like interface
const home = new SmartHomeFacade();
home.goodMorning();
home.movieNight();
home.goodNight();
 
// Note: Subsystems never communicate with each other
// Facade is just orchestrating one-time scene setups

home-automation-mediator.ts
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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
// ═══════════════════════════════════════════════════════════════════
// HOME AUTOMATION WITH MEDIATOR
// Purpose: Coordinate ongoing interactions between smart devices
// ═══════════════════════════════════════════════════════════════════
 
// Smart devices that need to coordinate their behavior
 
interface SmartHomeMediator {
    notify(device: SmartDevice, event: string, data?: any): void;
}
 
abstract class SmartDevice {
    protected mediator: SmartHomeMediator;
    protected name: string;
    
    constructor(name: string, mediator: SmartHomeMediator) {
        this.name = name;
        this.mediator = mediator;
    }
    
    protected notifyChange(event: string, data?: any): void {
        this.mediator.notify(this, event, data);
    }
}
 
class MotionSensor extends SmartDevice {
    public detectMotion(room: string): void {
        console.log(`\n👁️ Motion detected in ${room}`);
        this.notifyChange("motion", { room });
    }
    
    public noMotion(room: string): void {
        console.log(`\n😴 No motion in ${room} for 10 minutes`);
        this.notifyChange("no-motion", { room });
    }
}
 
class SmartLight extends SmartDevice {
    private brightness: number = 0;
    
    public setBrightness(level: number): void {
        this.brightness = level;
        console.log(`  💡 ${this.name} set to ${level}%`);
    }
    
    public getBrightness(): number {
        return this.brightness;
    }
}
 
class SmartThermostat extends SmartDevice {
    private currentTemp: number = 70;
    private targetTemp: number = 70;
    
    public setTarget(temp: number): void {
        this.targetTemp = temp;
        console.log(`  🌡️ Target temperature: ${temp}°F`);
        this.notifyChange("target-changed", { temp });
    }
    
    public reportTemperature(temp: number): void {
        this.currentTemp = temp;
        console.log(`  📊 Current temperature: ${temp}°F`);
        this.notifyChange("temp-reading", { temp, target: this.targetTemp });
    }
}
 
class SmartBlinds extends SmartDevice {
    private position: number = 0;
    
    public setPosition(position: number): void {
        this.position = position;
        console.log(`  🪟 ${this.name} set to ${position}%`);
        this.notifyChange("blinds-changed", { position });
    }
    
    public getPosition(): number {
        return this.position;
    }
}
 
class DoorSensor extends SmartDevice {
    public doorOpened(): void {
        console.log(`\n🚪 Front door opened`);
        this.notifyChange("door-opened", {});
    }
    
    public doorClosed(): void {
        console.log(`\n🚪 Front door closed`);
        this.notifyChange("door-closed", {});
    }
}
 
/**
 * Mediator coordinates device interactions
 * 
 * Devices react to each other's events through the mediator.
 * This enables smart automation rules.
 */
class SmartHomeController implements SmartHomeMediator {
    private motionSensor: MotionSensor;
    private livingRoomLight: SmartLight;
    private bedroomLight: SmartLight;
    private thermostat: SmartThermostat;
    private blinds: SmartBlinds;
    private doorSensor: DoorSensor;
    
    public initialize(): void {
        this.motionSensor = new MotionSensor("Motion Sensor", this);
        this.livingRoomLight = new SmartLight("Living Room Light", this);
        this.bedroomLight = new SmartLight("Bedroom Light", this);
        this.thermostat = new SmartThermostat("Thermostat", this);
        this.blinds = new SmartBlinds("Smart Blinds", this);
        this.doorSensor = new DoorSensor("Door Sensor", this);
    }
    
    /**
     * Central coordination logic - devices interact through here
     */
    public notify(device: SmartDevice, event: string, data?: any): void {
        console.log(`  📬 Mediator received: ${event}`);
        
        // RULE: Motion detected → turn on lights in that room
        if (event === "motion") {
            const room = data.room;
            if (room === "living room") {
                this.livingRoomLight.setBrightness(80);
            } else if (room === "bedroom") {
                this.bedroomLight.setBrightness(50);
            }
        }
        
        // RULE: No motion → turn off lights after delay
        if (event === "no-motion") {
            const room = data.room;
            if (room === "living room") {
                this.livingRoomLight.setBrightness(0);
            } else if (room === "bedroom") {
                this.bedroomLight.setBrightness(0);
            }
        }
        
        // RULE: Temperature too high → open blinds to cool
        if (event === "temp-reading") {
            if (data.temp > data.target + 5) {
                console.log(`  🔥 Too hot! Opening blinds to cool down.`);
                this.blinds.setPosition(0);  // Close blinds to block sun
            }
        }
        
        // RULE: Door opened → turn on entry lights
        if (event === "door-opened") {
            this.livingRoomLight.setBrightness(100);
        }
        
        // RULE: Blinds closed → may need artificial light
        if (event === "blinds-changed" && data.position === 0) {
            if (this.livingRoomLight.getBrightness() > 0) {
                // Boost light since natural light reduced
                console.log(`  💡 Boosting lights due to closed blinds`);
                this.livingRoomLight.setBrightness(
                    Math.min(100, this.livingRoomLight.getBrightness() + 20)
                );
            }
        }
    }
    
    // Accessors for simulation
    public getDevices() {
        return {
            motionSensor: this.motionSensor,
            thermostat: this.thermostat,
            doorSensor: this.doorSensor,
            blinds: this.blinds,
        };
    }
}
 
// Usage: Ongoing device coordination
const controller = new SmartHomeController();
controller.initialize();
 
const { motionSensor, thermostat, doorSensor } = controller.getDevices();
 
// Simulate real-time device events
motionSensor.detectMotion("living room");   // → lights turn on
thermostat.reportTemperature(82);           // → blinds close → lights boost
doorSensor.doorOpened();                    // → entry lights on
motionSensor.noMotion("living room");       // → lights turn off

The critical difference:

The Facade provides simple commands (movieNight(), goodMorning()) that orchestrate subsystems for one-time operations. Subsystems don't interact with each other.
The Mediator enables ongoing device interaction. When motion is detected, lights respond. When temperature changes, blinds adjust. Devices are peers in an ongoing coordination relationship.

Hybrid Scenarios: Using Both Patterns

In complex systems, you might need both patterns working together. This isn't pattern abuse—it's appropriate separation of concerns.

hybrid-example.ts
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
// ═══════════════════════════════════════════════════════════════════
// HYBRID: Facade + Mediator in Smart Home
// ═══════════════════════════════════════════════════════════════════
 
/**
 * Scenario: Smart home has both:
 * 1. Simple scene commands for users (Facade use case)
 * 2. Ongoing device coordination (Mediator use case)
 * 
 * Solution: Facade provides user interface, Mediator handles device coordination
 */
 
// The Mediator handles ongoing device interactions (as before)
class DeviceCoordinator implements SmartHomeMediator {
    // ... device coordination logic ...
    notify(device: SmartDevice, event: string, data?: any): void {
        // Coordinate device interactions
    }
}
 
// The Facade provides simple user commands
// It can ALSO trigger mediator-coordinated behaviors
class SmartHomeUserInterface {
    private deviceCoordinator: DeviceCoordinator;
    
    constructor(coordinator: DeviceCoordinator) {
        this.deviceCoordinator = coordinator;
    }
    
    // Facade methods for simple user commands
    public activateMovieMode(): void {
        console.log("\n🎬 Activating Movie Mode...");
        
        // Some actions are simple facade orchestration
        // (subsystems don't need to coordinate)
        this.deviceCoordinator.setLights("living room", 10);
        this.deviceCoordinator.closeBlinds();
        this.deviceCoordinator.powerOnTV();
        
        // But we also switch the mediator to "movie mode"
        // which affects ongoing coordination rules
        this.deviceCoordinator.setMode("movie");
        // Now motion sensors won't turn lights on high, etc.
    }
    
    public activateAwayMode(): void {
        console.log("\n🚪 Activating Away Mode...");
        
        // Set everything to away state
        this.deviceCoordinator.setAllLights(0);
        this.deviceCoordinator.armSecurity();
        
        // Switch coordination mode
        this.deviceCoordinator.setMode("away");
        // Now motion triggers security alerts instead of lights
    }
}
 
// Usage:
// - User interacts with Facade (simple commands)
// - Devices interact through Mediator (ongoing coordination)
// - Facade can influence Mediator's behavior (change modes)

Hybrid Pattern Responsibilities
Concern	Pattern Used	Responsibility
User commands	Facade	Simple scene activation, mode switching
Device coordination	Mediator	Ongoing interaction rules, event handling
External API	Facade	Hide internal complexity from apps/voice assistants
Automation rules	Mediator	Manage complex multi-device behaviors

Design Principle

Decision Framework: Which Pattern to Use

Use this decision framework when you're unsure which pattern applies:

Ask These Questions

•Do the objects know about the coordinator? → If they hold a reference and call it: likely Mediator. If they're completely unaware: likely Facade.
•Is communication bidirectional? → If coordinator calls back into objects: likely Mediator. If it only aggregates/delegates: likely Facade.
•Are the objects peers or subsystem components? → Peers that collaborate: Mediator. Components that together provide a capability: Facade.
•Is coordination ongoing or one-time? → Ongoing dynamic behavior: Mediator. Discrete operations: Facade.
•What's the primary goal? → Eliminate coupling between objects: Mediator. Simplify interface for external clients: Facade.

Pattern Selection Quick Reference
Indicator	Choose Mediator	Choose Facade
Object-coordinator relationship	Bidirectional	Unidirectional (coordinator → objects)
Objects aware of coordinator	Yes	No
Primary problem	Object coupling	Interface complexity
Interaction duration	Ongoing	Per-request
Typical examples	Chat rooms, dialogs, game entities	Libraries, SDKs, complex subsystems

Common Mistake

Don't choose based on superficial structure. A class that 'coordinates' multiple objects could be either pattern. Always analyze the communication flow and intent.

Summary: Mediator vs Facade

We've thoroughly compared the Mediator and Facade patterns. Let's consolidate the key distinctions:

Key Takeaways

•Mediator encapsulates behavior; Facade simplifies interface — These are fundamentally different intents solving different problems
•Mediator involves bidirectional communication — Colleagues notify the mediator, and the mediator calls back into colleagues
•Facade involves unidirectional delegation — Clients call facade, facade orchestrates subsystem, subsystems return results
•Mediated objects know they're mediated — They hold mediator references and actively participate
•Facade subsystems are unaware — They're just components being used; they don't reference the facade
•Both patterns can coexist — Use Facade for external simplification and Mediator for internal coordination

What's next:

Page Complete

3 / 4