Facade Pattern - Learning Module

Loading content...

0/246

Solution: Simplified Unified Interface

The Facade Pattern Solution

Having established the pain of complex subsystem interfaces in the previous page, we now turn to the Facade pattern—a structural design pattern that provides an elegant, principled solution. The Facade pattern's core insight is deceptively simple: interpose a higher-level interface between clients and the subsystem that exposes only what clients actually need.

This is not merely a 'wrapper' or a collection of utility functions. The Facade pattern represents a deliberate architectural decision to manage complexity through interface simplification while preserving full access to the underlying subsystem for advanced use cases.

What You Will Learn

By the end of this page, you will understand the Facade pattern's structure and mechanics, see concrete before/after examples of Facade application, grasp how Facade addresses each pain point from the previous page, and learn the key principles that make Facades effective.

Defining the Facade Pattern

Let's begin with a precise definition of the Facade pattern, drawing from its original formulation in the Gang of Four (GoF) design patterns book while expanding on the underlying concepts.

Gang of Four Definition

Facade: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

— Design Patterns: Elements of Reusable Object-Oriented Software

Unpacking the Definition

"Unified interface to a set of interfaces" — The subsystem exposes multiple interfaces (multiple classes with multiple methods). The Facade consolidates interactions into a single entry point, presenting one coherent interface instead of many disparate ones.

"Higher-level interface" — The Facade operates at a higher level of abstraction than the subsystem. Where the subsystem deals with implementation details (turn on amplifier, set input source, configure audio), the Facade deals with user intentions (watch a movie, listen to music).

"Makes the subsystem easier to use" — The primary goal is usability for clients. Clients can accomplish their tasks with less code, less knowledge, and less risk of error.

The Facade's Role

A Facade serves as an intermediary that:

Translates high-level client requests into sequences of subsystem operations
Coordinates multiple subsystem components to accomplish tasks
Encapsulates knowledge of which subsystem classes to use and how
Shields clients from subsystem complexity and changes
Provides sensible defaults while allowing customization

Crucially, the Facade does not replace the subsystem interface—it supplements it. Clients who need the full power of the subsystem can still access individual components directly. The Facade is an additional option, not a restriction.

Pattern Structure and Participants

The Facade pattern involves three main participants that work together to simplify subsystem access. Understanding each participant's role is essential for implementing the pattern effectively.

Facade Pattern Participants
Participant	Role	Responsibilities
Facade	Simplified Interface	Provides high-level methods that coordinate subsystem operations; knows which subsystem classes handle which requests; delegates client requests to appropriate subsystem objects
Subsystem Classes	Implementation	Implement subsystem functionality; handle work delegated by Facade; have no knowledge of the Facade—they don't keep references to it
Client	Consumer	Uses the Facade to accomplish high-level tasks; may access subsystem directly for advanced operations; decoupled from subsystem internals when using Facade

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
// SUBSYSTEM CLASSES
// These classes implement the actual functionality
// They are not aware of the Facade - no back-references
 
class SubsystemA {
    operationA1(): void { /* implementation */ }
    operationA2(): void { /* implementation */ }
}
 
class SubsystemB {
    operationB1(): void { /* implementation */ }
    operationB2(param: string): void { /* implementation */ }
}
 
class SubsystemC {
    operationC1(): void { /* implementation */ }
    operationC2(): void { /* implementation */ }
    operationC3(config: Config): void { /* implementation */ }
}
 
// FACADE
// Provides simplified interface to the subsystem
// Coordinates subsystem classes to accomplish high-level tasks
 
class Facade {
    private subsystemA: SubsystemA;
    private subsystemB: SubsystemB;
    private subsystemC: SubsystemC;
 
    constructor() {
        // Facade owns and manages subsystem instances
        // Alternatively, could receive them via dependency injection
        this.subsystemA = new SubsystemA();
        this.subsystemB = new SubsystemB();
        this.subsystemC = new SubsystemC();
    }
 
    /**
     * High-level operation that coordinates multiple subsystem calls
     * Client calls one method instead of knowing the subsystem details
     */
    performTask(): void {
        // Facade knows the correct sequence and configuration
        this.subsystemA.operationA1();
        this.subsystemB.operationB1();
        this.subsystemC.operationC1();
        this.subsystemC.operationC3({ /* default config */ });
    }
 
    /**
     * Another high-level operation with different coordination
     */
    performAnotherTask(input: string): void {
        this.subsystemB.operationB2(input);
        this.subsystemA.operationA2();
        this.subsystemC.operationC2();
    }
}
 
// CLIENT
// Uses Facade for simple cases
// Can still access subsystem directly if needed
 
class Client {
    private facade: Facade;
 
    constructor(facade: Facade) {
        this.facade = facade;
    }
 
    doWork(): void {
        // Simple: just call the Facade
        this.facade.performTask();
    }
}

Key Structural Insight

Notice the unidirectional dependency: the Facade depends on subsystem classes, but subsystem classes do not depend on the Facade. This is crucial—it means subsystem classes remain reusable, testable, and unaware of how they're being coordinated.

Concrete Example: Home Theater Facade

Let's apply the Facade pattern to the home theater example from the previous page. Recall that watching a movie required coordinating six different components with specific sequencing. A Facade transforms this complex coordination into a simple, intention-revealing interface.

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
/**
 * HomeTheaterFacade provides a simplified interface to the
 * complex home theater subsystem.
 * 
 * Clients can watch movies, listen to music, or perform other
 * high-level operations without knowing the underlying complexity.
 */
class HomeTheaterFacade {
    private amplifier: Amplifier;
    private dvdPlayer: DvdPlayer;
    private projector: Projector;
    private screen: Screen;
    private lights: TheaterLights;
    private surroundSound: SurroundSoundSystem;
 
    constructor(
        amplifier: Amplifier,
        dvdPlayer: DvdPlayer,
        projector: Projector,
        screen: Screen,
        lights: TheaterLights,
        surroundSound: SurroundSoundSystem
    ) {
        this.amplifier = amplifier;
        this.dvdPlayer = dvdPlayer;
        this.projector = projector;
        this.screen = screen;
        this.lights = lights;
        this.surroundSound = surroundSound;
    }
 
    /**
     * Watch a movie with optimal settings.
     * Coordinates all components in the correct sequence.
     */
    watchMovie(movie: string): void {
        console.log(`\n🎬 Getting ready to watch "${movie}"...\n`);
        
        // The Facade encapsulates the entire coordination sequence
        this.lights.dim(10);
        this.screen.down();
        this.projector.on();
        this.projector.setWideScreenMode();
        this.projector.setInput(this.dvdPlayer);
        this.amplifier.on();
        this.amplifier.setInputSource(InputSource.DVD);
        this.amplifier.setSurroundSound();
        this.amplifier.setVolume(50);
        this.surroundSound.on();
        this.surroundSound.setMode(SoundMode.MOVIE);
        this.dvdPlayer.on();
        this.dvdPlayer.play(movie);
        
        console.log(`\n🎬 Enjoy the movie!\n`);
    }
 
    /**
     * End the movie and return to normal state.
     * Handles shutdown sequence correctly.
     */
    endMovie(): void {
        console.log("\n🔌 Shutting down the home theater...\n");
        
        this.dvdPlayer.stop();
        this.dvdPlayer.eject();
        this.dvdPlayer.off();
        this.surroundSound.off();
        this.amplifier.off();
        this.projector.off();
        this.screen.up();
        this.lights.on();
        
        console.log("\n🔌 Home theater shut down.\n");
    }
 
    /**
     * Listen to music with appropriate audio settings.
     * Different configuration than movie mode.
     */
    listenToMusic(playlist: string): void {
        console.log(`\n🎵 Setting up for music: "${playlist}"...\n`);
        
        // Different sequence/configuration for music
        this.lights.dim(30);  // Brighter than movies
        this.amplifier.on();
        this.amplifier.setInputSource(InputSource.STREAMING);
        this.amplifier.setStereoSound();  // Stereo, not surround
        this.amplifier.setVolume(40);
        // No projector, screen, or DVD needed for music
        
        console.log(`\n🎵 Music playing!\n`);
    }
 
    /**
     * Quick shutdown - turns everything off.
     * Useful for emergency or when leaving quickly.
     */
    emergencyShutdown(): void {
        console.log("\n⚠️ Emergency shutdown...\n");
        
        this.amplifier.off();
        this.dvdPlayer.off();
        this.projector.off();
        this.surroundSound.off();
        this.screen.up();
        this.lights.on();
        
        console.log("\n⚠️ All systems off.\n");
    }
}

Comparing Client Code: Before and After

The transformation in client code is dramatic. What once required intimate knowledge of six classes now requires only a single, intention-revealing method call.

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
// Client must know ALL components
const amp = new Amplifier();
const dvd = new DvdPlayer();
const proj = new Projector();
const screen = new Screen();
const lights = new TheaterLights();
const sound = new SurroundSoundSystem();
 
// Client must know the sequence
lights.dim(10);
screen.down();
proj.on();
proj.setWideScreenMode();
proj.setInput(dvd);
amp.on();
amp.setInputSource(InputSource.DVD);
amp.setSurroundSound();
amp.setVolume(50);
sound.on();
sound.setMode(SoundMode.MOVIE);
dvd.on();
dvd.play("Inception");
 
// 12+ lines of coordination code
// Easy to miss a step or get order wrong

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Client only knows the Facade
const theater = new HomeTheaterFacade(
    amp, dvd, proj, screen, 
    lights, sound
);
 
// Single, intention-revealing call
theater.watchMovie("Inception");
 
 
 
 
 
 
 
 
 
// 1 line of client code
// Impossible to miss steps
// Impossible to get order wrong

How Facade Addresses Each Pain Point

In the previous page, we identified specific pain points that arise from complex subsystem interfaces. Let's systematically examine how the Facade pattern addresses each one.

Pain Points Addressed by Facade

•Steep Learning Curve → Reduced Surface Area — Instead of learning 6 classes with 30+ methods, clients learn 1 class with 4-5 high-level methods. The Facade's interface is organized around user intentions, not implementation details.
•Error-Prone Integration → Encapsulated Protocols — The complex sequencing and coordination logic lives inside the Facade, not scattered across clients. Clients can't forget steps or get the order wrong—the Facade ensures correctness.
•Verbose, Repetitive Code → Single Call Operations — What took 12 lines across all clients now takes 1 line. Code duplication is eliminated because coordination logic exists in exactly one place.
•Tight Coupling → Localized Dependencies — Clients depend only on the Facade, not on 6 subsystem classes. The explosion of dependency edges (8 clients × 6 classes = 48 edges) collapses to (8 clients × 1 Facade = 8 edges).
•Testing Difficulties → Single Mock Target — Testing client code requires mocking only the Facade, not multiple subsystem classes. Test setup becomes dramatically simpler.

Change Insulation

Perhaps most importantly, the Facade provides insulation against subsystem changes. Consider the scenario from the previous page: the Projector's setWideScreenMode() method gains new parameters.

Without Facade: Every client that calls this method must be updated.

With Facade: Only the Facade's implementation changes. Client code remains unchanged because clients don't call subsystem methods directly—they call Facade methods that have stable signatures.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// When subsystem changes...
class Projector {
    // OLD: setWideScreenMode(): void
    // NEW: setWideScreenMode(aspectRatio: AspectRatio, overscan: boolean): void
    setWideScreenMode(aspectRatio: AspectRatio, overscan: boolean): void {
        // implementation
    }
}
 
// Only the Facade needs to change
class HomeTheaterFacade {
    watchMovie(movie: string): void {
        // Update just this one location
        // Clients calling watchMovie() are unaffected
        this.projector.setWideScreenMode(AspectRatio.RATIO_16_9, false);
        // ... rest unchanged
    }
}
 
// Client code: ZERO CHANGES REQUIRED
theater.watchMovie("Inception"); // Still works exactly the same

Real-World Example: Database Access Facade

Let's apply the Facade pattern to the database access example from the previous page. Recall the complex interaction involving connection pools, transactions, statements, parameter binding, and result set handling. A Facade can dramatically simplify this while preserving the underlying flexibility for advanced use cases.

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
/**
 * DatabaseFacade provides a simplified interface for common
 * database operations while encapsulating the complexity of
 * connection management, transactions, and resource handling.
 */
class DatabaseFacade {
    private connectionPool: ConnectionPool;
    private transactionManager: TransactionManager;
    private statementFactory: StatementFactory;
    private parameterBinder: ParameterBinder;
    private exceptionTranslator: ExceptionTranslator;
 
    constructor(config: DatabaseConfig) {
        // Initialize all subsystem components
        this.connectionPool = new ConnectionPool(config);
        this.transactionManager = new TransactionManager();
        this.statementFactory = new StatementFactory();
        this.parameterBinder = new ParameterBinder();
        this.exceptionTranslator = new ExceptionTranslator();
    }
 
    /**
     * Execute a query and map results using the provided mapper.
     * Handles all connection, transaction, and resource management.
     */
    async query<T>(
        sql: string, 
        params: QueryParam[], 
        mapper: RowMapper<T>
    ): Promise<T[]> {
        let connection: Connection | null = null;
        let statement: PreparedStatement | null = null;
        let resultSet: ResultSet | null = null;
 
        try {
            connection = await this.connectionPool.acquire();
            await connection.validate();
 
            statement = this.statementFactory.createPrepared(connection, sql);
            this.bindParameters(statement, params);
 
            await this.transactionManager.begin(connection);
            resultSet = await statement.executeQuery();
            await this.transactionManager.commit(connection);
 
            return this.mapResults(resultSet, mapper);
 
        } catch (error) {
            await this.handleError(connection, error);
            throw this.exceptionTranslator.translate(error);
 
        } finally {
            await this.cleanup(resultSet, statement, connection);
        }
    }
 
    /**
     * Execute a single query expecting exactly one result.
     * Throws if zero or multiple results found.
     */
    async queryOne<T>(
        sql: string, 
        params: QueryParam[], 
        mapper: RowMapper<T>
    ): Promise<T> {
        const results = await this.query(sql, params, mapper);
        if (results.length === 0) {
            throw new NoResultException('Expected exactly one result, got zero');
        }
        if (results.length > 1) {
            throw new TooManyResultsException(`Expected one result, got ${results.length}`);
        }
        return results[0];
    }
 
    /**
     * Execute a query expecting zero or one result.
     */
    async queryOptional<T>(
        sql: string, 
        params: QueryParam[], 
        mapper: RowMapper<T>
    ): Promise<T | null> {
        const results = await this.query(sql, params, mapper);
        if (results.length > 1) {
            throw new TooManyResultsException(`Expected at most one result, got ${results.length}`);
        }
        return results.length === 1 ? results[0] : null;
    }
 
    /**
     * Execute an insert/update/delete and return affected row count.
     */
    async execute(sql: string, params: QueryParam[]): Promise<number> {
        let connection: Connection | null = null;
        let statement: PreparedStatement | null = null;
 
        try {
            connection = await this.connectionPool.acquire();
            statement = this.statementFactory.createPrepared(connection, sql);
            this.bindParameters(statement, params);
 
            await this.transactionManager.begin(connection);
            const affectedRows = await statement.executeUpdate();
            await this.transactionManager.commit(connection);
 
            return affectedRows;
 
        } catch (error) {
            await this.handleError(connection, error);
            throw this.exceptionTranslator.translate(error);
 
        } finally {
            await this.cleanup(null, statement, connection);
        }
    }
 
    /**
     * Execute multiple operations within a single transaction.
     */
    async executeInTransaction<T>(
        operation: (tx: TransactionContext) => Promise<T>
    ): Promise<T> {
        const connection = await this.connectionPool.acquire();
        const context = new TransactionContext(
            connection, 
            this.statementFactory, 
            this.parameterBinder
        );
 
        try {
            await this.transactionManager.begin(connection);
            const result = await operation(context);
            await this.transactionManager.commit(connection);
            return result;
 
        } catch (error) {
            await this.transactionManager.rollback(connection);
            throw this.exceptionTranslator.translate(error);
 
        } finally {
            await this.connectionPool.release(connection);
        }
    }
 
    // Private helper methods encapsulate common logic
    private bindParameters(statement: PreparedStatement, params: QueryParam[]): void {
        params.forEach((param, index) => {
            this.parameterBinder.bind(statement, index + 1, param.value, param.type);
        });
    }
 
    private async mapResults<T>(resultSet: ResultSet, mapper: RowMapper<T>): Promise<T[]> {
        const results: T[] = [];
        while (await resultSet.next()) {
            results.push(mapper.mapRow(resultSet));
        }
        return results;
    }
 
    private async handleError(connection: Connection | null, error: Error): Promise<void> {
        if (connection && this.transactionManager.isActive(connection)) {
            await this.transactionManager.rollback(connection);
        }
    }
 
    private async cleanup(
        resultSet: ResultSet | null, 
        statement: PreparedStatement | null, 
        connection: Connection | null
    ): Promise<void> {
        if (resultSet) await resultSet.close();
        if (statement) await statement.close();
        if (connection) await this.connectionPool.release(connection);
    }
}

Client Code Transformation

With the DatabaseFacade, the UserRepository becomes dramatically simpler:

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
class UserRepository {
    private db: DatabaseFacade;
 
    constructor(db: DatabaseFacade) {
        // Single dependency instead of six
        this.db = db;
    }
 
    async findById(userId: string): Promise<User | null> {
        // One line instead of 30+
        return this.db.queryOptional(
            "SELECT * FROM users WHERE id = ?",
            [{ value: userId, type: SqlType.VARCHAR }],
            new UserRowMapper()
        );
    }
 
    async findByEmail(email: string): Promise<User | null> {
        return this.db.queryOptional(
            "SELECT * FROM users WHERE email = ?",
            [{ value: email, type: SqlType.VARCHAR }],
            new UserRowMapper()
        );
    }
 
    async findAll(): Promise<User[]> {
        return this.db.query(
            "SELECT * FROM users ORDER BY created_at DESC",
            [],
            new UserRowMapper()
        );
    }
 
    async save(user: User): Promise<void> {
        await this.db.execute(
            "INSERT INTO users (id, name, email) VALUES (?, ?, ?)",
            [
                { value: user.id, type: SqlType.VARCHAR },
                { value: user.name, type: SqlType.VARCHAR },
                { value: user.email, type: SqlType.VARCHAR },
            ]
        );
    }
 
    async transferCredits(fromId: string, toId: string, amount: number): Promise<void> {
        // Complex operation still supported via executeInTransaction
        await this.db.executeInTransaction(async (tx) => {
            await tx.execute(
                "UPDATE users SET credits = credits - ? WHERE id = ?",
                [{ value: amount, type: SqlType.INTEGER }, { value: fromId, type: SqlType.VARCHAR }]
            );
            await tx.execute(
                "UPDATE users SET credits = credits + ? WHERE id = ?",
                [{ value: amount, type: SqlType.INTEGER }, { value: toId, type: SqlType.VARCHAR }]
            );
        });
    }
}

Designing the Facade Interface

The effectiveness of a Facade depends heavily on the quality of its interface design. A poorly designed Facade can become another layer of complexity rather than a simplification. Here are the principles that guide effective Facade interface design.

Principle 1: Intention-Revealing Names

Facade methods should be named for what clients want to accomplish, not what the subsystem does. Think in terms of user goals, not implementation steps.

✗ turnOnAmplifierSetSurroundSoundLowerScreen() ✓ watchMovie(movieTitle)

✗ acquireConnectionPrepareStatementBindExecuteRelease() ✓ query(sql, params)

Principle 2: Minimal Parameter Sets

Facade methods should require only the information that clients naturally have—the parameters that express their intent. Implementation details should be handled internally with sensible defaults.

✗ watchMovie(title, volume, lightLevel, aspectRatio, audioMode, inputSource) ✓ watchMovie(title) — with optional MovieOptions for customization

If clients frequently need to customize, provide overloads or configuration objects rather than long parameter lists.

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
// Option 1: Sensible defaults with optional overrides
class HomeTheaterFacade {
    watchMovie(title: string, options?: MovieOptions): void {
        const config = {
            volume: options?.volume ?? 50,
            lightLevel: options?.lightLevel ?? 10,
            soundMode: options?.soundMode ?? SoundMode.SURROUND,
            aspectRatio: options?.aspectRatio ?? AspectRatio.WIDESCREEN,
        };
        
        // Use config values instead of hardcoded defaults
        this.lights.dim(config.lightLevel);
        this.amplifier.setVolume(config.volume);
        // ...
    }
}
 
// Most clients use the simple version
theater.watchMovie("Inception");
 
// Clients with specific needs can customize
theater.watchMovie("Inception", { 
    volume: 70, 
    lightLevel: 0,  // Complete darkness
    soundMode: SoundMode.DOLBY_ATMOS 
});
 
// Option 2: Fluent configuration for complex cases
const movieSession = theater.prepareMovie("Inception")
    .withVolume(70)
    .withLighting(LightingMode.DARK)
    .withSubtitles("English")
    .build();
 
movieSession.start();

Principle 3: Cohesive Operations

Each Facade method should represent a complete, coherent operation. Clients should not need to call multiple Facade methods in sequence to accomplish a single task—that would just move the coordination problem from subsystem level to Facade level.

✗ setupVideo() → setupAudio() → startPlayback() — splitting a single task ✓ watchMovie() — one method, complete operation

Principle 4: Consistent Abstraction Level

All Facade methods should operate at the same level of abstraction. Mixing high-level convenience methods with low-level utility methods creates confusion about the Facade's purpose.

✗ Mixing watchMovie(), listenToMusic() with setAmplifierInputSource(), calibrateProjector() ✓ Keep all methods at the same level; expose subsystem for low-level needs

Preserving Direct Subsystem Access

A critical but often overlooked aspect of the Facade pattern is that the Facade supplements rather than replaces the subsystem interface. Clients who need capabilities beyond what the Facade provides must still be able to access the subsystem directly.

Common Mistake: Hiding the Subsystem

Some implementations mistakenly make the subsystem inaccessible, forcing all operations through the Facade. This violates the pattern's intent and creates problems when clients have legitimate needs for direct subsystem access.

When Clients Need Direct Access

Advanced Configuration: A client needs to calibrate the projector manually—an operation too specialized for the Facade.
Non-Standard Use Cases: The Facade covers 90% of use cases, but a client has a unique requirement.
Performance Optimization: Direct access avoids Facade overhead for hot paths.
Incremental Migration: Existing code uses the subsystem directly; it's being gradually migrated to use the Facade.

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
class HomeTheaterFacade {
    // Subsystem components are private but can be exposed via getters
    private readonly amplifier: Amplifier;
    private readonly projector: Projector;
    // ... other components
 
    // High-level operations for most clients
    watchMovie(title: string): void { /* ... */ }
    listenToMusic(playlist: string): void { /* ... */ }
 
    // Escape hatch: Provide access to subsystem for advanced use cases
    // Two common approaches:
 
    // Approach 1: Getters for individual components
    getAmplifier(): Amplifier {
        return this.amplifier;
    }
 
    getProjector(): Projector {
        return this.projector;
    }
 
    // Approach 2: Return subsystem bundle for full access
    getSubsystem(): HomeTheaterSubsystem {
        return {
            amplifier: this.amplifier,
            projector: this.projector,
            dvdPlayer: this.dvdPlayer,
            screen: this.screen,
            lights: this.lights,
            surroundSound: this.surroundSound,
        };
    }
}
 
// Client uses Facade for simple cases
theater.watchMovie("Inception");
 
// Client with advanced needs accesses subsystem directly
const projector = theater.getProjector();
projector.calibrate();
projector.setCustomColorProfile(advancedProfile);
 
// Or gets full subsystem access
const subsystem = theater.getSubsystem();
// Now has full control for complex, one-off scenarios

Usage Tracking

If you find that many clients are bypassing the Facade to access the subsystem directly, it's a signal that the Facade might be missing important high-level operations. Consider adding new Facade methods to cover these use cases.

Summary: The Facade Solution

We've now thoroughly explored the Facade pattern's solution to complex subsystem interfaces. Let's consolidate the key concepts.

Key Takeaways

•Facade provides a unified, simplified interface — A single class with high-level methods replaces the need for clients to interact with multiple subsystem classes.
•Facade encapsulates coordination logic — Sequencing, configuration, and proper component interaction are handled inside the Facade, not duplicated across clients.
•Facade reduces coupling — Clients depend on one class instead of many, dramatically reducing dependency edges and change propagation.
•Facade is supplementary, not restrictive — The subsystem remains accessible for clients with advanced needs; Facade is an additional option.
•Effective Facades have intention-revealing interfaces — Method names and parameters express user goals, not implementation details.
•Subsystem classes remain independent — They have no knowledge of or dependency on the Facade, preserving their reusability and testability.

What's Next

In the next page, we'll explore Facade design considerations—the nuanced decisions that affect Facade effectiveness, including when to create multiple Facades, how to handle subsystem evolution, testing strategies, and common pitfalls to avoid.

Page Complete

You now understand the Facade pattern's solution: a unified, simplified interface that addresses subsystem complexity while preserving access to the full subsystem. The pattern transforms client code from verbose, coupled, error-prone sequences into simple, intention-revealing method calls.