System Design LLDFacade Pattern

Facade Pattern: Simplifying Complex Subsystems

LevelIntermediate

Duration50 mins

TopicFacade Pattern

3 / 4

Facade Design Considerations

Beyond the Basic Pattern

Understanding the Facade pattern's structure and intent is the first step; applying it effectively in real-world systems requires deeper consideration. Production systems present challenges that textbook examples gloss over: subsystems evolve, multiple client groups have different needs, Facades themselves can become complex, and testing requires thoughtful strategies.

This page explores the nuanced design decisions that separate adequate Facades from excellent ones—the considerations that experienced engineers weigh when designing Facades that will serve their systems well for years.

What You Will Learn

By the end of this page, you will understand when to use multiple Facades, how to evolve Facades as requirements change, strategies for testing Facade-based systems, performance considerations, and common pitfalls that undermine Facade effectiveness.

Single vs. Multiple Facades

The classic Facade pattern shows a single Facade class. But real-world subsystems often serve multiple client groups with different needs. Should you create one comprehensive Facade or multiple specialized Facades? The answer depends on your specific context.

Single Facade: When It Works

A single Facade is appropriate when:

All clients need roughly the same high-level operations
The set of operations is manageable (fewer than 15-20 methods)
There's a single, coherent mental model for using the subsystem
The Facade interface remains stable over time

Multiple Facades: When They're Needed

Multiple specialized Facades become necessary when:

Different client groups have distinctly different needs
A single Facade would become bloated (>20 methods)
Different operations have different authorization requirements
Clients differ in their level of sophistication

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
// E-commerce Order Subsystem with Multiple Facades
 
// Customer-facing facade: simple, safe operations
class CustomerOrderFacade {
    async placeOrder(cart: ShoppingCart, payment: PaymentInfo): Promise<Order> {
        // Handles inventory check, payment, confirmation email
    }
 
    async getOrderStatus(orderId: string): Promise<OrderStatus> {
        // Read-only access to order status
    }
 
    async cancelOrder(orderId: string): Promise<void> {
        // Limited to cancellable orders, handles refund
    }
 
    async requestReturn(orderId: string, items: ReturnItem[]): Promise<ReturnRequest> {
        // Initiates return process
    }
}
 
// Operations-facing facade: more control, monitoring focus
class OperationsOrderFacade {
    async getOrdersByStatus(status: OrderStatus): Promise<Order[]> {
        // Bulk retrieval for monitoring dashboards
    }
 
    async getOrderMetrics(timeRange: TimeRange): Promise<OrderMetrics> {
        // Aggregate statistics for operations
    }
 
    async flagOrderForReview(orderId: string, reason: string): Promise<void> {
        // Mark orders that need human attention
    }
 
    async reassignWarehouse(orderId: string, warehouseId: string): Promise<void> {
        // Redirect order to different fulfillment center
    }
}
 
// Admin-facing facade: full power, audit-logged
class AdminOrderFacade {
    async forceRefund(orderId: string, amount: Money, reason: string): Promise<void> {
        // Override normal refund rules
    }
 
    async overrideOrderStatus(orderId: string, newStatus: OrderStatus): Promise<void> {
        // Manual status correction (audit logged)
    }
 
    async adjustInventory(sku: string, adjustment: number, reason: string): Promise<void> {
        // Manual inventory correction
    }
 
    async getFullOrderHistory(orderId: string): Promise<AuditLog[]> {
        // Complete audit trail access
    }
}
 
// All three facades use the same underlying subsystem
// But expose different operations at different safety/trust levels

Single vs Multiple Facades: Decision Factors
Factor	Single Facade	Multiple Facades
Client Diversity	Homogeneous client needs	Diverse client groups (customers, admins, operations)
Interface Size	Manageable (<15-20 methods)	Would become bloated
Authorization	Uniform access rights	Different access levels
Evolution	Changes together	Different parts evolve independently
Discovery	Easy to find THE facade	May need guidance to find the right facade

Layered Facades

Multiple Facades don't have to duplicate code. Higher-level Facades can delegate to lower-level ones, creating a layered architecture. For example, CustomerOrderFacade.placeOrder() might internally use operations from a shared OrderCoreFacade that handles common logic.

Choosing the Right Granularity

Beyond the single-vs-multiple decision, Facade designers must determine the granularity of Facade operations. Should each method do one small thing, or should it handle large, complex operations? The answer lies in understanding your clients' natural interaction patterns.

Coarse-Grained Facades

Coarse-grained Facades provide high-level operations that accomplish complete tasks in a single call.

Advantages:

Maximum simplicity for clients
Strong encapsulation of subsystem complexity
Fewer round-trips in distributed scenarios
Easier to maintain transaction boundaries

Disadvantages:

Less flexibility for uncommon use cases
May do more than some clients need
Harder to compose for novel scenarios

Fine-Grained Facades

Fine-grained Facades provide smaller operations that clients compose to accomplish tasks.

Advantages:

More flexibility and composability
Clients take only what they need
Easier to add new operations without bloating existing ones

Disadvantages:

Clients must still understand operation sequences
Risk of reintroducing the complexity Facade should eliminate
More round-trips, potentially worse performance

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
// COARSE-GRAINED: Complete operation in one call
class CoarseUserRegistrationFacade {
    async registerUser(
        userInfo: UserRegistrationInfo
    ): Promise<RegistrationResult> {
        // Does EVERYTHING: validation, account creation, 
        // verification email, welcome notification, 
        // analytics tracking, default preferences setup
        // All in one call
    }
}
 
// Usage: One call does everything
const result = await facade.registerUser({
    email: "user@example.com",
    name: "John Doe",
    password: "secure123"
});
 
// FINE-GRAINED: Separate operations, client composes
class FineGrainedUserFacade {
    async createAccount(credentials: UserCredentials): Promise<User> { /* ... */ }
    async sendVerificationEmail(userId: string): Promise<void> { /* ... */ }
    async sendWelcomeNotification(userId: string): Promise<void> { /* ... */ }
    async setupDefaultPreferences(userId: string): Promise<void> { /* ... */ }
    async trackRegistration(userId: string): Promise<void> { /* ... */ }
}
 
// Usage: Client must compose
const user = await facade.createAccount(credentials);
await facade.sendVerificationEmail(user.id);
await facade.sendWelcomeNotification(user.id);
await facade.setupDefaultPreferences(user.id);
await facade.trackRegistration(user.id);
// Client is back to managing sequences... is this still a Facade?
 
// BALANCED: Coarse defaults with hooks for customization
class BalancedUserFacade {
    async registerUser(
        userInfo: UserRegistrationInfo,
        options: RegistrationOptions = {}
    ): Promise<RegistrationResult> {
        const user = await this.createAccount(userInfo);
        
        if (options.skipVerification !== true) {
            await this.sendVerificationEmail(user.id);
        }
        
        if (options.skipWelcome !== true) {
            await this.sendWelcomeNotification(user.id);
        }
        
        await this.setupDefaultPreferences(user.id);
        await this.trackRegistration(user.id);
        
        return { user, verificationSent: !options.skipVerification };
    }
}
 
// Usage: Simple by default, flexible when needed
await facade.registerUser(userInfo); // Normal case
await facade.registerUser(userInfo, { skipVerification: true }); // Custom case

The 'Obvious Next Step' Heuristic

When designing Facade granularity, ask: 'After calling this method, is there an obvious next step that clients will almost always take?' If yes, consider including that step in the method. If the next step varies significantly across clients, keep them separate.

Evolving the Subsystem Behind the Facade

One of Facade's key benefits is insulating clients from subsystem changes. But this insulation requires intentional design. As the subsystem evolves, the Facade must evolve with it—ideally without forcing changes on clients.

Types of Subsystem Changes

Internal changes (transparent to clients):

Implementation refactoring within subsystem classes
Adding new subsystem classes that Facade uses internally
Performance optimizations in subsystem
Bug fixes in subsystem behavior

Interface changes (potentially visible to clients):

New required parameters on subsystem methods
Changed return types or error conditions
Deprecated subsystem classes replaced with new ones
New capabilities clients might want access to

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
// Original subsystem API
class PaymentProcessor {
    processPayment(amount: number, cardToken: string): PaymentResult {
        // Original simple implementation
    }
}
 
// Subsystem evolves: new fraud detection, new parameters
class PaymentProcessor {
    processPayment(
        amount: number, 
        cardToken: string,
        fraudContext: FraudContext,  // NEW
        idempotencyKey: string       // NEW
    ): PaymentResult {
        // Enhanced implementation with fraud checks
    }
}
 
// Facade absorbs the change
class PaymentFacade {
    private fraudContextBuilder: FraudContextBuilder;
    private idempotencyGenerator: IdempotencyKeyGenerator;
 
    async pay(amount: Money): Promise<PaymentConfirmation> {
        // Facade constructs the new required parameters internally
        const fraudContext = this.fraudContextBuilder.build({
            ipAddress: this.requestContext.ip,
            deviceId: this.requestContext.deviceId,
            userHistory: await this.getUserRiskProfile()
        });
        
        const idempotencyKey = this.idempotencyGenerator.generate();
        
        // Client code unchanged - still calls pay(amount)
        return this.paymentProcessor.processPayment(
            amount.toCents(),
            this.tokenVault.getToken(),
            fraudContext,
            idempotencyKey
        );
    }
}
 
// Client code: ZERO CHANGES
await paymentFacade.pay(Money.dollars(99.99));

Facade Versioning Strategies

When subsystem changes require Facade interface changes (new functionality clients need), consider these strategies:

Strategy 1: Additive Changes Add new methods to the Facade without modifying existing ones. Old clients continue using old methods; new clients use new methods.

Strategy 2: Optional Parameters Add new parameters with default values so existing callers aren't affected.

Strategy 3: Versioned Facades Create new Facade versions (PaymentFacadeV2) while maintaining the old version. Allows gradual migration.

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
// Strategy 1: Additive Changes
class PaymentFacade {
    // Original method unchanged
    async pay(amount: Money): Promise<PaymentConfirmation> { /* ... */ }
    
    // New method for new capability
    async payWithInstallments(
        amount: Money, 
        installments: number
    ): Promise<InstallmentPaymentConfirmation> { /* ... */ }
}
 
// Strategy 2: Optional Parameters with Backwards Compatibility
class PaymentFacade {
    async pay(
        amount: Money, 
        options?: PaymentOptions  // Optional, defaults available
    ): Promise<PaymentConfirmation> {
        const effectiveOptions = {
            installments: options?.installments ?? 1,
            currency: options?.currency ?? Currency.USD,
            saveCard: options?.saveCard ?? false,
            ...options
        };
        // Process with effective options
    }
}
 
// Old code still works
await facade.pay(Money.dollars(100));
 
// New code uses new features
await facade.pay(Money.dollars(100), { installments: 3 });
 
// Strategy 3: Versioned Facades (for breaking changes)
interface PaymentFacade {
    pay(amount: Money): Promise<PaymentConfirmation>;
}
 
class PaymentFacadeV1 implements PaymentFacade {
    // Original implementation
    async pay(amount: Money): Promise<PaymentConfirmation> { /* V1 logic */ }
}
 
class PaymentFacadeV2 implements PaymentFacade {
    // Enhanced implementation with different behavior
    async pay(amount: Money): Promise<PaymentConfirmation> { /* V2 logic */ }
    
    // V2-only methods
    async payWithWallet(wallet: DigitalWallet): Promise<PaymentConfirmation> { /* ... */ }
}
 
// Migration: Inject V2 when ready, V1 until then

Testing Facade-Based Systems

Facades introduce a layer of indirection, which has implications for testing. A thoughtful testing strategy treats the Facade, subsystem, and clients as separate concerns with different testing approaches.

Testing the Facade Itself

Facade tests verify that the Facade correctly coordinates subsystem components:

Unit Tests: Mock subsystem components; verify Facade calls them in correct order with correct arguments
Integration Tests: Use real subsystem components; verify end-to-end operations work
Edge Cases: Test error handling, partial failures, timeout scenarios

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
describe('HomeTheaterFacade', () => {
    let facade: HomeTheaterFacade;
    let mockAmplifier: jest.Mocked<Amplifier>;
    let mockProjector: jest.Mocked<Projector>;
    let mockScreen: jest.Mocked<Screen>;
    let mockLights: jest.Mocked<TheaterLights>;
    let mockDvdPlayer: jest.Mocked<DvdPlayer>;
 
    beforeEach(() => {
        // Create mocks for all subsystem components
        mockAmplifier = createMockAmplifier();
        mockProjector = createMockProjector();
        mockScreen = createMockScreen();
        mockLights = createMockTheaterLights();
        mockDvdPlayer = createMockDvdPlayer();
 
        facade = new HomeTheaterFacade(
            mockAmplifier,
            mockDvdPlayer,
            mockProjector,
            mockScreen,
            mockLights
        );
    });
 
    describe('watchMovie', () => {
        it('should turn on components in correct order', async () => {
            const callOrder: string[] = [];
            
            mockLights.dim.mockImplementation(() => { 
                callOrder.push('lights.dim'); 
            });
            mockScreen.down.mockImplementation(() => { 
                callOrder.push('screen.down'); 
            });
            mockProjector.on.mockImplementation(() => { 
                callOrder.push('projector.on'); 
            });
            mockAmplifier.on.mockImplementation(() => { 
                callOrder.push('amplifier.on'); 
            });
            mockDvdPlayer.play.mockImplementation(() => { 
                callOrder.push('dvd.play'); 
            });
 
            facade.watchMovie('Inception');
 
            // Verify correct sequencing
            expect(callOrder.indexOf('lights.dim'))
                .toBeLessThan(callOrder.indexOf('projector.on'));
            expect(callOrder.indexOf('screen.down'))
                .toBeLessThan(callOrder.indexOf('dvd.play'));
            expect(callOrder.indexOf('amplifier.on'))
                .toBeLessThan(callOrder.indexOf('dvd.play'));
        });
 
        it('should configure amplifier with surround sound for movies', () => {
            facade.watchMovie('Inception');
 
            expect(mockAmplifier.setSurroundSound).toHaveBeenCalled();
            expect(mockAmplifier.setVolume).toHaveBeenCalledWith(
                expect.any(Number)
            );
        });
 
        it('should handle component failure gracefully', async () => {
            mockProjector.on.mockImplementation(() => {
                throw new Error('Projector overheated');
            });
 
            await expect(facade.watchMovie('Inception'))
                .rejects.toThrow('Projector overheated');
            
            // Verify cleanup was attempted
            expect(mockLights.on).toHaveBeenCalled(); // Restore lights
        });
    });
});

Testing Client Code That Uses Facades

Clients that use Facades benefit from simplified testing—mock only the Facade, not the entire subsystem:

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
describe('MovieNightService', () => {
    let service: MovieNightService;
    let mockFacade: jest.Mocked<HomeTheaterFacade>;
 
    beforeEach(() => {
        // Only need ONE mock, not six
        mockFacade = {
            watchMovie: jest.fn().mockResolvedValue(undefined),
            endMovie: jest.fn().mockResolvedValue(undefined),
            listenToMusic: jest.fn().mockResolvedValue(undefined),
        } as jest.Mocked<HomeTheaterFacade>;
 
        service = new MovieNightService(mockFacade);
    });
 
    describe('startMovieNight', () => {
        it('should play the selected movie', async () => {
            await service.startMovieNight('Inception');
 
            expect(mockFacade.watchMovie).toHaveBeenCalledWith('Inception');
        });
 
        it('should track viewing history', async () => {
            await service.startMovieNight('Inception');
 
            expect(service.getViewingHistory()).toContain('Inception');
        });
    });
});
 
// Compare to testing WITHOUT Facade:
// Would need to mock: Amplifier, DvdPlayer, Projector, 
// Screen, TheaterLights, SurroundSoundSystem
// Setup would be 50+ lines instead of 5

Facade Testing Best Practices

•Test Facade coordination logic with unit tests — Mock subsystem, verify method calls and ordering
•Test Facade error handling explicitly — Subsystem components can fail; verify Facade handles failures gracefully
•Integration test the Facade with real subsystem — Verify end-to-end behavior works as expected
•Client tests mock only the Facade — This is the key benefit: simplified client testing
•Test subsystem classes independently — They should be tested in isolation, not just through the Facade

Performance Considerations

Facades add a layer of indirection, which has performance implications. In most cases, this overhead is negligible compared to the complexity benefits. But in performance-critical paths, the considerations merit attention.

Method Call Overhead

The basic overhead of Facade method calls is typically insignificant:

One extra method invocation per operation
Modern JIT compilers often inline such calls
Measured overhead: typically nanoseconds

When it matters: Ultra-high-frequency operations (millions per second) in tight loops. Even then, measure before optimizing.

Object Creation Overhead

If the Facade creates temporary objects (result objects, configuration objects), this can have measurable impact:

Object allocation has a cost
Garbage collection pressure increases with object churn
Consider object pooling or reuse for hot paths

Mitigation: Reuse objects where possible; use value types in languages that support them; benchmark before over-optimizing.

Network Boundaries and Facades

When Facades represent remote services (common in distributed systems), performance considerations change dramatically:

Network latency dominates (milliseconds, not nanoseconds)
Facade granularity directly affects round-trips
Coarse-grained Facades minimize network calls
Consider batching and caching strategies

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
// INEFFICIENT: Fine-grained remote facade
// Each call is a network round-trip
interface UserRemoteFacade {
    getUser(userId: string): Promise<User>;
    getUserProfile(userId: string): Promise<UserProfile>;
    getUserPreferences(userId: string): Promise<UserPreferences>;
    getUserActivityHistory(userId: string): Promise<Activity[]>;
}
 
// Client code: 4 network round-trips!
const user = await remoteFacade.getUser(userId);
const profile = await remoteFacade.getUserProfile(userId);
const prefs = await remoteFacade.getUserPreferences(userId);
const history = await remoteFacade.getUserActivityHistory(userId);
 
// EFFICIENT: Coarse-grained remote facade
// Single round-trip returns everything needed
interface UserRemoteFacade {
    getUserComplete(userId: string): Promise<UserCompleteData>;
}
 
interface UserCompleteData {
    user: User;
    profile: UserProfile;
    preferences: UserPreferences;
    recentActivity: Activity[];  // Last N items, not full history
}
 
// Client code: 1 network round-trip
const userData = await remoteFacade.getUserComplete(userId);
 
// BALANCED: Composite operations + selective fetching
interface UserRemoteFacade {
    getUser(userId: string): Promise<User>;  // Basic info, fast
    
    getUserWithDetails(
        userId: string, 
        include: UserDetailOptions
    ): Promise<UserWithDetails>;  // Selective fetching
}
 
// Client specifies what they need
const userData = await remoteFacade.getUserWithDetails(userId, {
    includeProfile: true,
    includePreferences: true,
    includeActivity: false  // Don't need this, skip the extra work
});

Measure, Don't Assume

Performance concerns about Facades are often overblown. The abstraction benefits usually far outweigh any overhead. Always measure actual performance impact before adding complexity for 'optimization.' Premature optimization of Facade overhead is a common anti-pattern.

Common Facade Pitfalls

Even well-intentioned Facade implementations can fall into traps that undermine their effectiveness. Recognizing these pitfalls helps you avoid them in your designs.

Pitfall 1: The God Facade

Symptom: A Facade that grows to encompass every possible subsystem operation, becoming a bloated, unfocused class with 50+ methods.

Why it happens: Developers add every new operation to the existing Facade rather than considering whether it belongs there.

Solution: Keep Facades focused. When a Facade exceeds 15-20 methods, consider splitting into multiple specialized Facades. Not every subsystem operation needs to be in a Facade.

Pitfall 2: The Leaky Facade

Symptom: Facade methods expose subsystem implementation details—returning internal types, throwing internal exceptions, or requiring subsystem-specific parameters.

Why it happens: Developers pass through subsystem interfaces without translation.

Solution: Define Facade-specific types for parameters and returns. Translate exceptions into Facade-level exceptions. Hide subsystem types behind abstractions.

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
// LEAKY FACADE: Exposes subsystem types
class PaymentFacade {
    // Leaky: Returns database entity directly
    async getTransaction(id: string): Promise<TransactionEntity> { /* ... */ }
    
    // Leaky: Exposes internal exception
    async pay(amount: number): Promise<PaymentResult> {
        try {
            // ...
        } catch (e) {
            // Leaky: throws internal exception
            throw new StripeApiException(e.message);
        }
    }
    
    // Leaky: Requires knowledge of internal enum
    async payWithMethod(method: StripePaymentMethodType): Promise<PaymentResult> { /* ... */ }
}
 
// PROPER FACADE: Clean abstraction boundary
class PaymentFacade {
    // Clean: Returns facade-owned type
    async getTransaction(id: string): Promise<Transaction> {
        const entity = await this.repo.findById(id);
        return this.mapToTransaction(entity);  // Translation layer
    }
    
    // Clean: Facade-level exceptions
    async pay(amount: number): Promise<PaymentResult> {
        try {
            // ...
        } catch (e) {
            // Translated exception
            throw new PaymentFailedException(
                'Payment could not be processed', 
                { cause: e }
            );
        }
    }
    
    // Clean: Facade-owned enum
    async payWithMethod(method: PaymentMethod): Promise<PaymentResult> {
        const internalMethod = this.mapToStripeMethod(method);  // Internal translation
        // ...
    }
}

Pitfall 3: The Unnecessary Facade

Symptom: A Facade is created for a subsystem that isn't actually complex—perhaps just 2-3 classes with straightforward interfaces.

Why it happens: Pattern enthusiasm leads to applying Facade everywhere, regardless of need.

Solution: Use Facade when there's genuine complexity to hide. For simple subsystems, direct usage may be clearer. Ask: 'What complexity is this Facade eliminating?'

Pitfall 4: The Anemic Facade

Symptom: A Facade that merely forwards calls to subsystem classes without adding any value—no coordination, no simplification, no sensible defaults.

Why it happens: Facade created 'for the future' without present benefit, or as an attempt to 'wrap everything.'

Solution: Facades should add value through coordination, simplification, or abstraction. If a Facade method is just return this.subsystem.doThing(), question whether it's needed.

Pitfall 5: The Prison Facade

Symptom: Facade prevents access to underlying subsystem, forcing all operations through Facade even when clients have legitimate needs for direct access.

Why it happens: Misunderstanding that Facade should hide, not supplement, the subsystem.

Solution: Provide escape hatches for advanced use cases. The Facade pattern explicitly allows direct subsystem access; don't use Facade as an access control mechanism.

Facade in Combination with Other Patterns

Facades often work in concert with other design patterns. Understanding these combinations helps you design more sophisticated, flexible systems.

Facade + Abstract Factory

Use Abstract Factory to create the subsystem components that the Facade coordinates. This allows different subsystem implementations (test vs. production, local vs. remote) while maintaining the same Facade 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
// Abstract Factory creates subsystem components
interface HomeTheaterFactory {
    createAmplifier(): Amplifier;
    createProjector(): Projector;
    createDvdPlayer(): DvdPlayer;
    createLights(): TheaterLights;
    createScreen(): Screen;
}
 
// Production factory creates real components
class ProductionHomeTheaterFactory implements HomeTheaterFactory {
    createAmplifier(): Amplifier { return new YamahaAmplifier(); }
    createProjector(): Projector { return new EpsonProjector(); }
    // ...
}
 
// Test factory creates mocks/stubs
class TestHomeTheaterFactory implements HomeTheaterFactory {
    createAmplifier(): Amplifier { return new MockAmplifier(); }
    createProjector(): Projector { return new MockProjector(); }
    // ...
}
 
// Facade accepts factory, uses created components
class HomeTheaterFacade {
    constructor(factory: HomeTheaterFactory) {
        this.amplifier = factory.createAmplifier();
        this.projector = factory.createProjector();
        this.dvdPlayer = factory.createDvdPlayer();
        this.lights = factory.createLights();
        this.screen = factory.createScreen();
    }
    
    watchMovie(title: string): void { /* ... */ }
}
 
// Usage
const productionFacade = new HomeTheaterFacade(new ProductionHomeTheaterFactory());
const testFacade = new HomeTheaterFacade(new TestHomeTheaterFactory());

Facade + Singleton

For subsystems that should have exactly one instance throughout the application, combine Facade with Singleton. Be cautious: this makes the Facade a global access point, which can complicate testing.

Facade + Adapter

When integrating with external systems or legacy code, Adapters can normalize divergent interfaces, and a Facade can then present a unified view of the adapted components.

Facade + Mediator

Both patterns coordinate component interactions, but they differ in intent:

Facade: Simplifies access to a subsystem (one-way: client → subsystem)
Mediator: Coordinates communication among peers (two-way: components ↔ mediator ↔ components)

A Facade might internally use a Mediator to coordinate complex subsystem interactions.

Facade Combinations
Pattern Combination	Use Case
Facade + Abstract Factory	Swappable subsystem implementations (test, production, different vendors)
Facade + Singleton	Single global access point to subsystem (use carefully)
Facade + Adapter	Unified interface over heterogeneous legacy/external systems
Facade + Proxy	Add cross-cutting concerns (logging, caching, access control) to Facade operations
Facade + Decorator	Dynamically add behavior to Facade operations

Summary: Facade Design Mastery

We've explored the nuanced design decisions that elevate Facade implementations from basic to excellent. Let's consolidate the key insights.

Key Design Considerations

•Single vs. Multiple Facades — Use multiple Facades when different client groups have distinctly different needs
•Granularity — Prefer coarse-grained operations that accomplish complete tasks; provide customization via optional parameters
•Evolution Strategy — Design for subsystem changes to be absorbed in the Facade; use additive changes and versioning
•Testing — Test Facade coordination with mocked subsystem; test clients by mocking only the Facade
•Performance — Overhead is usually negligible; for remote Facades, coarse granularity minimizes network calls
•Avoid Pitfalls — Don't create God Facades, Leaky Facades, Unnecessary Facades, Anemic Facades, or Prison Facades
•Pattern Combinations — Facade works well with Factory, Singleton, Adapter, and other patterns

What's Next

In the final page of this module, we'll examine real-world use cases and examples—how the Facade pattern manifests in popular frameworks, libraries, and production systems you likely use every day.

Page Complete

You now understand the design considerations that make Facades effective in production systems: when to use multiple Facades, how to choose granularity, strategies for evolution, testing approaches, performance considerations, and pitfalls to avoid.

3 / 4

Loading learning content...

System Design LLDFacade Pattern

Facade Pattern: Simplifying Complex Subsystems

LevelIntermediate

Duration50 mins

TopicFacade Pattern

3 / 4

Facade Design Considerations

Beyond the Basic Pattern

What You Will Learn

Single vs. Multiple Facades

Single Facade: When It Works

A single Facade is appropriate when:

All clients need roughly the same high-level operations
The set of operations is manageable (fewer than 15-20 methods)
There's a single, coherent mental model for using the subsystem
The Facade interface remains stable over time

Multiple Facades: When They're Needed

Multiple specialized Facades become necessary when:

Different client groups have distinctly different needs
A single Facade would become bloated (>20 methods)
Different operations have different authorization requirements
Clients differ in their level of sophistication

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
// E-commerce Order Subsystem with Multiple Facades
 
// Customer-facing facade: simple, safe operations
class CustomerOrderFacade {
    async placeOrder(cart: ShoppingCart, payment: PaymentInfo): Promise<Order> {
        // Handles inventory check, payment, confirmation email
    }
 
    async getOrderStatus(orderId: string): Promise<OrderStatus> {
        // Read-only access to order status
    }
 
    async cancelOrder(orderId: string): Promise<void> {
        // Limited to cancellable orders, handles refund
    }
 
    async requestReturn(orderId: string, items: ReturnItem[]): Promise<ReturnRequest> {
        // Initiates return process
    }
}
 
// Operations-facing facade: more control, monitoring focus
class OperationsOrderFacade {
    async getOrdersByStatus(status: OrderStatus): Promise<Order[]> {
        // Bulk retrieval for monitoring dashboards
    }
 
    async getOrderMetrics(timeRange: TimeRange): Promise<OrderMetrics> {
        // Aggregate statistics for operations
    }
 
    async flagOrderForReview(orderId: string, reason: string): Promise<void> {
        // Mark orders that need human attention
    }
 
    async reassignWarehouse(orderId: string, warehouseId: string): Promise<void> {
        // Redirect order to different fulfillment center
    }
}
 
// Admin-facing facade: full power, audit-logged
class AdminOrderFacade {
    async forceRefund(orderId: string, amount: Money, reason: string): Promise<void> {
        // Override normal refund rules
    }
 
    async overrideOrderStatus(orderId: string, newStatus: OrderStatus): Promise<void> {
        // Manual status correction (audit logged)
    }
 
    async adjustInventory(sku: string, adjustment: number, reason: string): Promise<void> {
        // Manual inventory correction
    }
 
    async getFullOrderHistory(orderId: string): Promise<AuditLog[]> {
        // Complete audit trail access
    }
}
 
// All three facades use the same underlying subsystem
// But expose different operations at different safety/trust levels

Single vs Multiple Facades: Decision Factors
Factor	Single Facade	Multiple Facades
Client Diversity	Homogeneous client needs	Diverse client groups (customers, admins, operations)
Interface Size	Manageable (<15-20 methods)	Would become bloated
Authorization	Uniform access rights	Different access levels
Evolution	Changes together	Different parts evolve independently
Discovery	Easy to find THE facade	May need guidance to find the right facade

Layered Facades

Choosing the Right Granularity

Coarse-Grained Facades

Coarse-grained Facades provide high-level operations that accomplish complete tasks in a single call.

Advantages:

Maximum simplicity for clients
Strong encapsulation of subsystem complexity
Fewer round-trips in distributed scenarios
Easier to maintain transaction boundaries

Disadvantages:

Less flexibility for uncommon use cases
May do more than some clients need
Harder to compose for novel scenarios

Fine-Grained Facades

Fine-grained Facades provide smaller operations that clients compose to accomplish tasks.

Advantages:

More flexibility and composability
Clients take only what they need
Easier to add new operations without bloating existing ones

Disadvantages:

Clients must still understand operation sequences
Risk of reintroducing the complexity Facade should eliminate
More round-trips, potentially worse performance

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
// COARSE-GRAINED: Complete operation in one call
class CoarseUserRegistrationFacade {
    async registerUser(
        userInfo: UserRegistrationInfo
    ): Promise<RegistrationResult> {
        // Does EVERYTHING: validation, account creation, 
        // verification email, welcome notification, 
        // analytics tracking, default preferences setup
        // All in one call
    }
}
 
// Usage: One call does everything
const result = await facade.registerUser({
    email: "user@example.com",
    name: "John Doe",
    password: "secure123"
});
 
// FINE-GRAINED: Separate operations, client composes
class FineGrainedUserFacade {
    async createAccount(credentials: UserCredentials): Promise<User> { /* ... */ }
    async sendVerificationEmail(userId: string): Promise<void> { /* ... */ }
    async sendWelcomeNotification(userId: string): Promise<void> { /* ... */ }
    async setupDefaultPreferences(userId: string): Promise<void> { /* ... */ }
    async trackRegistration(userId: string): Promise<void> { /* ... */ }
}
 
// Usage: Client must compose
const user = await facade.createAccount(credentials);
await facade.sendVerificationEmail(user.id);
await facade.sendWelcomeNotification(user.id);
await facade.setupDefaultPreferences(user.id);
await facade.trackRegistration(user.id);
// Client is back to managing sequences... is this still a Facade?
 
// BALANCED: Coarse defaults with hooks for customization
class BalancedUserFacade {
    async registerUser(
        userInfo: UserRegistrationInfo,
        options: RegistrationOptions = {}
    ): Promise<RegistrationResult> {
        const user = await this.createAccount(userInfo);
        
        if (options.skipVerification !== true) {
            await this.sendVerificationEmail(user.id);
        }
        
        if (options.skipWelcome !== true) {
            await this.sendWelcomeNotification(user.id);
        }
        
        await this.setupDefaultPreferences(user.id);
        await this.trackRegistration(user.id);
        
        return { user, verificationSent: !options.skipVerification };
    }
}
 
// Usage: Simple by default, flexible when needed
await facade.registerUser(userInfo); // Normal case
await facade.registerUser(userInfo, { skipVerification: true }); // Custom case

The 'Obvious Next Step' Heuristic

Evolving the Subsystem Behind the Facade

Types of Subsystem Changes

Internal changes (transparent to clients):

Implementation refactoring within subsystem classes
Adding new subsystem classes that Facade uses internally
Performance optimizations in subsystem
Bug fixes in subsystem behavior

Interface changes (potentially visible to clients):

New required parameters on subsystem methods
Changed return types or error conditions
Deprecated subsystem classes replaced with new ones
New capabilities clients might want access to

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
// Original subsystem API
class PaymentProcessor {
    processPayment(amount: number, cardToken: string): PaymentResult {
        // Original simple implementation
    }
}
 
// Subsystem evolves: new fraud detection, new parameters
class PaymentProcessor {
    processPayment(
        amount: number, 
        cardToken: string,
        fraudContext: FraudContext,  // NEW
        idempotencyKey: string       // NEW
    ): PaymentResult {
        // Enhanced implementation with fraud checks
    }
}
 
// Facade absorbs the change
class PaymentFacade {
    private fraudContextBuilder: FraudContextBuilder;
    private idempotencyGenerator: IdempotencyKeyGenerator;
 
    async pay(amount: Money): Promise<PaymentConfirmation> {
        // Facade constructs the new required parameters internally
        const fraudContext = this.fraudContextBuilder.build({
            ipAddress: this.requestContext.ip,
            deviceId: this.requestContext.deviceId,
            userHistory: await this.getUserRiskProfile()
        });
        
        const idempotencyKey = this.idempotencyGenerator.generate();
        
        // Client code unchanged - still calls pay(amount)
        return this.paymentProcessor.processPayment(
            amount.toCents(),
            this.tokenVault.getToken(),
            fraudContext,
            idempotencyKey
        );
    }
}
 
// Client code: ZERO CHANGES
await paymentFacade.pay(Money.dollars(99.99));

Facade Versioning Strategies

When subsystem changes require Facade interface changes (new functionality clients need), consider these strategies:

Strategy 1: Additive Changes Add new methods to the Facade without modifying existing ones. Old clients continue using old methods; new clients use new methods.

Strategy 2: Optional Parameters Add new parameters with default values so existing callers aren't affected.

Strategy 3: Versioned Facades Create new Facade versions (PaymentFacadeV2) while maintaining the old version. Allows gradual migration.

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
// Strategy 1: Additive Changes
class PaymentFacade {
    // Original method unchanged
    async pay(amount: Money): Promise<PaymentConfirmation> { /* ... */ }
    
    // New method for new capability
    async payWithInstallments(
        amount: Money, 
        installments: number
    ): Promise<InstallmentPaymentConfirmation> { /* ... */ }
}
 
// Strategy 2: Optional Parameters with Backwards Compatibility
class PaymentFacade {
    async pay(
        amount: Money, 
        options?: PaymentOptions  // Optional, defaults available
    ): Promise<PaymentConfirmation> {
        const effectiveOptions = {
            installments: options?.installments ?? 1,
            currency: options?.currency ?? Currency.USD,
            saveCard: options?.saveCard ?? false,
            ...options
        };
        // Process with effective options
    }
}
 
// Old code still works
await facade.pay(Money.dollars(100));
 
// New code uses new features
await facade.pay(Money.dollars(100), { installments: 3 });
 
// Strategy 3: Versioned Facades (for breaking changes)
interface PaymentFacade {
    pay(amount: Money): Promise<PaymentConfirmation>;
}
 
class PaymentFacadeV1 implements PaymentFacade {
    // Original implementation
    async pay(amount: Money): Promise<PaymentConfirmation> { /* V1 logic */ }
}
 
class PaymentFacadeV2 implements PaymentFacade {
    // Enhanced implementation with different behavior
    async pay(amount: Money): Promise<PaymentConfirmation> { /* V2 logic */ }
    
    // V2-only methods
    async payWithWallet(wallet: DigitalWallet): Promise<PaymentConfirmation> { /* ... */ }
}
 
// Migration: Inject V2 when ready, V1 until then

Testing Facade-Based Systems

Testing the Facade Itself

Facade tests verify that the Facade correctly coordinates subsystem components:

Unit Tests: Mock subsystem components; verify Facade calls them in correct order with correct arguments
Integration Tests: Use real subsystem components; verify end-to-end operations work
Edge Cases: Test error handling, partial failures, timeout scenarios

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
describe('HomeTheaterFacade', () => {
    let facade: HomeTheaterFacade;
    let mockAmplifier: jest.Mocked<Amplifier>;
    let mockProjector: jest.Mocked<Projector>;
    let mockScreen: jest.Mocked<Screen>;
    let mockLights: jest.Mocked<TheaterLights>;
    let mockDvdPlayer: jest.Mocked<DvdPlayer>;
 
    beforeEach(() => {
        // Create mocks for all subsystem components
        mockAmplifier = createMockAmplifier();
        mockProjector = createMockProjector();
        mockScreen = createMockScreen();
        mockLights = createMockTheaterLights();
        mockDvdPlayer = createMockDvdPlayer();
 
        facade = new HomeTheaterFacade(
            mockAmplifier,
            mockDvdPlayer,
            mockProjector,
            mockScreen,
            mockLights
        );
    });
 
    describe('watchMovie', () => {
        it('should turn on components in correct order', async () => {
            const callOrder: string[] = [];
            
            mockLights.dim.mockImplementation(() => { 
                callOrder.push('lights.dim'); 
            });
            mockScreen.down.mockImplementation(() => { 
                callOrder.push('screen.down'); 
            });
            mockProjector.on.mockImplementation(() => { 
                callOrder.push('projector.on'); 
            });
            mockAmplifier.on.mockImplementation(() => { 
                callOrder.push('amplifier.on'); 
            });
            mockDvdPlayer.play.mockImplementation(() => { 
                callOrder.push('dvd.play'); 
            });
 
            facade.watchMovie('Inception');
 
            // Verify correct sequencing
            expect(callOrder.indexOf('lights.dim'))
                .toBeLessThan(callOrder.indexOf('projector.on'));
            expect(callOrder.indexOf('screen.down'))
                .toBeLessThan(callOrder.indexOf('dvd.play'));
            expect(callOrder.indexOf('amplifier.on'))
                .toBeLessThan(callOrder.indexOf('dvd.play'));
        });
 
        it('should configure amplifier with surround sound for movies', () => {
            facade.watchMovie('Inception');
 
            expect(mockAmplifier.setSurroundSound).toHaveBeenCalled();
            expect(mockAmplifier.setVolume).toHaveBeenCalledWith(
                expect.any(Number)
            );
        });
 
        it('should handle component failure gracefully', async () => {
            mockProjector.on.mockImplementation(() => {
                throw new Error('Projector overheated');
            });
 
            await expect(facade.watchMovie('Inception'))
                .rejects.toThrow('Projector overheated');
            
            // Verify cleanup was attempted
            expect(mockLights.on).toHaveBeenCalled(); // Restore lights
        });
    });
});

Testing Client Code That Uses Facades

Clients that use Facades benefit from simplified testing—mock only the Facade, not the entire subsystem:

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
describe('MovieNightService', () => {
    let service: MovieNightService;
    let mockFacade: jest.Mocked<HomeTheaterFacade>;
 
    beforeEach(() => {
        // Only need ONE mock, not six
        mockFacade = {
            watchMovie: jest.fn().mockResolvedValue(undefined),
            endMovie: jest.fn().mockResolvedValue(undefined),
            listenToMusic: jest.fn().mockResolvedValue(undefined),
        } as jest.Mocked<HomeTheaterFacade>;
 
        service = new MovieNightService(mockFacade);
    });
 
    describe('startMovieNight', () => {
        it('should play the selected movie', async () => {
            await service.startMovieNight('Inception');
 
            expect(mockFacade.watchMovie).toHaveBeenCalledWith('Inception');
        });
 
        it('should track viewing history', async () => {
            await service.startMovieNight('Inception');
 
            expect(service.getViewingHistory()).toContain('Inception');
        });
    });
});
 
// Compare to testing WITHOUT Facade:
// Would need to mock: Amplifier, DvdPlayer, Projector, 
// Screen, TheaterLights, SurroundSoundSystem
// Setup would be 50+ lines instead of 5

Facade Testing Best Practices

•Test Facade coordination logic with unit tests — Mock subsystem, verify method calls and ordering
•Test Facade error handling explicitly — Subsystem components can fail; verify Facade handles failures gracefully
•Integration test the Facade with real subsystem — Verify end-to-end behavior works as expected
•Client tests mock only the Facade — This is the key benefit: simplified client testing
•Test subsystem classes independently — They should be tested in isolation, not just through the Facade

Performance Considerations

Method Call Overhead

The basic overhead of Facade method calls is typically insignificant:

One extra method invocation per operation
Modern JIT compilers often inline such calls
Measured overhead: typically nanoseconds

When it matters: Ultra-high-frequency operations (millions per second) in tight loops. Even then, measure before optimizing.

Object Creation Overhead

If the Facade creates temporary objects (result objects, configuration objects), this can have measurable impact:

Object allocation has a cost
Garbage collection pressure increases with object churn
Consider object pooling or reuse for hot paths

Mitigation: Reuse objects where possible; use value types in languages that support them; benchmark before over-optimizing.

Network Boundaries and Facades

When Facades represent remote services (common in distributed systems), performance considerations change dramatically:

Network latency dominates (milliseconds, not nanoseconds)
Facade granularity directly affects round-trips
Coarse-grained Facades minimize network calls
Consider batching and caching strategies

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
// INEFFICIENT: Fine-grained remote facade
// Each call is a network round-trip
interface UserRemoteFacade {
    getUser(userId: string): Promise<User>;
    getUserProfile(userId: string): Promise<UserProfile>;
    getUserPreferences(userId: string): Promise<UserPreferences>;
    getUserActivityHistory(userId: string): Promise<Activity[]>;
}
 
// Client code: 4 network round-trips!
const user = await remoteFacade.getUser(userId);
const profile = await remoteFacade.getUserProfile(userId);
const prefs = await remoteFacade.getUserPreferences(userId);
const history = await remoteFacade.getUserActivityHistory(userId);
 
// EFFICIENT: Coarse-grained remote facade
// Single round-trip returns everything needed
interface UserRemoteFacade {
    getUserComplete(userId: string): Promise<UserCompleteData>;
}
 
interface UserCompleteData {
    user: User;
    profile: UserProfile;
    preferences: UserPreferences;
    recentActivity: Activity[];  // Last N items, not full history
}
 
// Client code: 1 network round-trip
const userData = await remoteFacade.getUserComplete(userId);
 
// BALANCED: Composite operations + selective fetching
interface UserRemoteFacade {
    getUser(userId: string): Promise<User>;  // Basic info, fast
    
    getUserWithDetails(
        userId: string, 
        include: UserDetailOptions
    ): Promise<UserWithDetails>;  // Selective fetching
}
 
// Client specifies what they need
const userData = await remoteFacade.getUserWithDetails(userId, {
    includeProfile: true,
    includePreferences: true,
    includeActivity: false  // Don't need this, skip the extra work
});

Measure, Don't Assume

Common Facade Pitfalls

Even well-intentioned Facade implementations can fall into traps that undermine their effectiveness. Recognizing these pitfalls helps you avoid them in your designs.

Pitfall 1: The God Facade

Symptom: A Facade that grows to encompass every possible subsystem operation, becoming a bloated, unfocused class with 50+ methods.

Why it happens: Developers add every new operation to the existing Facade rather than considering whether it belongs there.

Solution: Keep Facades focused. When a Facade exceeds 15-20 methods, consider splitting into multiple specialized Facades. Not every subsystem operation needs to be in a Facade.

Pitfall 2: The Leaky Facade

Symptom: Facade methods expose subsystem implementation details—returning internal types, throwing internal exceptions, or requiring subsystem-specific parameters.

Why it happens: Developers pass through subsystem interfaces without translation.

Solution: Define Facade-specific types for parameters and returns. Translate exceptions into Facade-level exceptions. Hide subsystem types behind abstractions.

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
// LEAKY FACADE: Exposes subsystem types
class PaymentFacade {
    // Leaky: Returns database entity directly
    async getTransaction(id: string): Promise<TransactionEntity> { /* ... */ }
    
    // Leaky: Exposes internal exception
    async pay(amount: number): Promise<PaymentResult> {
        try {
            // ...
        } catch (e) {
            // Leaky: throws internal exception
            throw new StripeApiException(e.message);
        }
    }
    
    // Leaky: Requires knowledge of internal enum
    async payWithMethod(method: StripePaymentMethodType): Promise<PaymentResult> { /* ... */ }
}
 
// PROPER FACADE: Clean abstraction boundary
class PaymentFacade {
    // Clean: Returns facade-owned type
    async getTransaction(id: string): Promise<Transaction> {
        const entity = await this.repo.findById(id);
        return this.mapToTransaction(entity);  // Translation layer
    }
    
    // Clean: Facade-level exceptions
    async pay(amount: number): Promise<PaymentResult> {
        try {
            // ...
        } catch (e) {
            // Translated exception
            throw new PaymentFailedException(
                'Payment could not be processed', 
                { cause: e }
            );
        }
    }
    
    // Clean: Facade-owned enum
    async payWithMethod(method: PaymentMethod): Promise<PaymentResult> {
        const internalMethod = this.mapToStripeMethod(method);  // Internal translation
        // ...
    }
}

Pitfall 3: The Unnecessary Facade

Symptom: A Facade is created for a subsystem that isn't actually complex—perhaps just 2-3 classes with straightforward interfaces.

Why it happens: Pattern enthusiasm leads to applying Facade everywhere, regardless of need.

Solution: Use Facade when there's genuine complexity to hide. For simple subsystems, direct usage may be clearer. Ask: 'What complexity is this Facade eliminating?'

Pitfall 4: The Anemic Facade

Symptom: A Facade that merely forwards calls to subsystem classes without adding any value—no coordination, no simplification, no sensible defaults.

Why it happens: Facade created 'for the future' without present benefit, or as an attempt to 'wrap everything.'

Solution: Facades should add value through coordination, simplification, or abstraction. If a Facade method is just return this.subsystem.doThing(), question whether it's needed.

Pitfall 5: The Prison Facade

Symptom: Facade prevents access to underlying subsystem, forcing all operations through Facade even when clients have legitimate needs for direct access.

Why it happens: Misunderstanding that Facade should hide, not supplement, the subsystem.

Solution: Provide escape hatches for advanced use cases. The Facade pattern explicitly allows direct subsystem access; don't use Facade as an access control mechanism.

Facade in Combination with Other Patterns

Facades often work in concert with other design patterns. Understanding these combinations helps you design more sophisticated, flexible systems.

Facade + Abstract Factory

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
// Abstract Factory creates subsystem components
interface HomeTheaterFactory {
    createAmplifier(): Amplifier;
    createProjector(): Projector;
    createDvdPlayer(): DvdPlayer;
    createLights(): TheaterLights;
    createScreen(): Screen;
}
 
// Production factory creates real components
class ProductionHomeTheaterFactory implements HomeTheaterFactory {
    createAmplifier(): Amplifier { return new YamahaAmplifier(); }
    createProjector(): Projector { return new EpsonProjector(); }
    // ...
}
 
// Test factory creates mocks/stubs
class TestHomeTheaterFactory implements HomeTheaterFactory {
    createAmplifier(): Amplifier { return new MockAmplifier(); }
    createProjector(): Projector { return new MockProjector(); }
    // ...
}
 
// Facade accepts factory, uses created components
class HomeTheaterFacade {
    constructor(factory: HomeTheaterFactory) {
        this.amplifier = factory.createAmplifier();
        this.projector = factory.createProjector();
        this.dvdPlayer = factory.createDvdPlayer();
        this.lights = factory.createLights();
        this.screen = factory.createScreen();
    }
    
    watchMovie(title: string): void { /* ... */ }
}
 
// Usage
const productionFacade = new HomeTheaterFacade(new ProductionHomeTheaterFactory());
const testFacade = new HomeTheaterFacade(new TestHomeTheaterFactory());

Facade + Singleton

For subsystems that should have exactly one instance throughout the application, combine Facade with Singleton. Be cautious: this makes the Facade a global access point, which can complicate testing.

Facade + Adapter

When integrating with external systems or legacy code, Adapters can normalize divergent interfaces, and a Facade can then present a unified view of the adapted components.

Facade + Mediator

Both patterns coordinate component interactions, but they differ in intent:

Facade: Simplifies access to a subsystem (one-way: client → subsystem)
Mediator: Coordinates communication among peers (two-way: components ↔ mediator ↔ components)

A Facade might internally use a Mediator to coordinate complex subsystem interactions.

Facade Combinations
Pattern Combination	Use Case
Facade + Abstract Factory	Swappable subsystem implementations (test, production, different vendors)
Facade + Singleton	Single global access point to subsystem (use carefully)
Facade + Adapter	Unified interface over heterogeneous legacy/external systems
Facade + Proxy	Add cross-cutting concerns (logging, caching, access control) to Facade operations
Facade + Decorator	Dynamically add behavior to Facade operations

Summary: Facade Design Mastery

We've explored the nuanced design decisions that elevate Facade implementations from basic to excellent. Let's consolidate the key insights.

Key Design Considerations

•Single vs. Multiple Facades — Use multiple Facades when different client groups have distinctly different needs
•Granularity — Prefer coarse-grained operations that accomplish complete tasks; provide customization via optional parameters
•Evolution Strategy — Design for subsystem changes to be absorbed in the Facade; use additive changes and versioning
•Testing — Test Facade coordination with mocked subsystem; test clients by mocking only the Facade
•Performance — Overhead is usually negligible; for remote Facades, coarse granularity minimizes network calls
•Avoid Pitfalls — Don't create God Facades, Leaky Facades, Unnecessary Facades, Anemic Facades, or Prison Facades
•Pattern Combinations — Facade works well with Factory, Singleton, Adapter, and other patterns

What's Next

Page Complete

3 / 4