Facade

Real-world analogy

When ordering a hot pepperoni pizza, you do not telephone the dairy farm for cheese, the flour mill for dough, the tomato wholesaler for sauce, and coordinate with an independent delivery courier. You open a food delivery application or call the pizzeria front desk. The front desk acts as a facade: it takes your order, handles payment, coordinates the kitchen, tracks the oven timer, and assigns a courier, presenting you with a single point of interaction.

The problem

You are building an e-commerce platform. When a customer confirms their shopping cart, the system must coordinate multiple complex subsystem services:

1. InventoryService: Verify stock and reserve SKUs.
2. PaymentService: Authorize credit card or digital wallet transaction.
3. FraudDetector: Score IP address, device fingerprint, and velocity.
4. ShippingService: Book warehouse fulfillment and generate tracking label.
5. NotificationService: Send confirmation email and push notification.

Without a Facade, every client (the web storefront, mobile app, recurring subscription worker, customer support portal) must manually orchestrate all five services:

1 // Naive implementation: Client directly coupled to all subsystem services
2 class MobileCheckoutController {
3   checkout(user, cart) {
4     const fraud = new FraudDetector();
5     if (fraud.isFraudulent(user, cart)) throw new Error("Fraud detected");
6 
7     const inventory = new InventoryService();
8     if (!inventory.checkStock(cart.items)) throw new Error("Out of stock");
9     inventory.reserve(cart.items);
10 
11     const payment = new PaymentService();
12     const charge = payment.charge(user.billing, cart.total);
13     if (!charge.success) {
14       inventory.release(cart.items);
15       throw new Error("Payment failed");
16     }
17 
18     const shipping = new ShippingService();
19     const tracking = shipping.schedulePickup(user.address, cart.items);
20 
21     const notifier = new NotificationService();
22     notifier.sendOrderConfirmation(user.email, charge.id, tracking.code);
23   }
24 }

1 public class Example {
2     static class MobileCheckoutController {
3         // High coupling: Controller must instantiate, configure, and orchestrate
4         // 5+ disparate subsystems, repeating the same sequence across all client apps.
5         public void checkout(String user, double amount) {
6             System.out.println("Manually coordinating 5 disparate services...");
7         }
8     }
9 
10     public

This architecture produces tight coupling between client UI controllers and backend subsystems. If ShippingService updates its API or requires address validation, every client caller must be modified.

The solution

The Facade pattern provides a unified, higher-level interface over a collection of subsystem interfaces. It encapsulates the complex interactions, ordering rules, and error recovery workflows behind a single method call.

• Facade (OrderCheckoutFacade): High-level entry point delegating to subsystem components.
• Subsystem Classes (Inventory, Payment, Shipping, Notification): Independent modules unaware of the Facade's existence.
• Client: Interacts solely with the Facade for common workflows, while retaining the freedom to invoke specific subsystems directly for advanced tasks.

Step-by-step implementation

Step 1: Define the independent subsystem components

The subsystem classes perform their specific domain tasks independently.

Step 2: Assemble the facade orchestrating the subsystem

The facade holds references to the subsystem instances and exposes a clean high-level method.

Step 3: Callers interact with the simplified facade

Clients need only one line of code to execute the entire end-to-end workflow.

1 const facade = new OrderCheckoutFacade(new InventoryService(), new PaymentService());
2 const confirmation = facade.placeOrder({ token: "card_tok_123" }, ["item_1"], 49.99);
3 console.log(`Order status: ${confirmation.orderId}`);

1 public class Example {
2     static class InventoryService { public boolean reserve(int c) { 

The complete example

Here is the complete runnable example demonstrating video conversion across complex subsystem decoders and encoders.

1 --- Starting conversion: raw_footage.mkv ---
2 Demuxer: Extracted audio stream from raw_footage.mkv
3 Demuxer: Extracted video stream from raw_footage.mkv
4 AudioMixer: Transcoded audio to AAC @ 192kbps
5 VideoTranscoder: Compressed video using H.264 at 1080p
6 Mp4Muxer: Packaged video and audio into container -> raw_footage.mp4
7 --- Completed conversion: raw_footage.mp4 ---
8 
9 --- Starting conversion: mobile_recording.avi ---
10 Demuxer: Extracted audio stream from mobile_recording.avi
11 Demuxer: Extracted video stream from mobile_recording.avi
12 AudioMixer: Transcoded audio to AAC @ 192kbps
13 VideoTranscoder: Compressed video using H.265 at 4K
14

Variations

Facade vs adapter

Engineers often confuse Facade and Adapter because both wrap existing classes:

• Adapter: Maps an existing, incompatible class to a pre-existing target interface that the client already relies on. It makes one specific class match another specific contract.
• Facade: Defines a brand-new, high-level interface that simplifies multiple classes. It is created to provide a convenient shorthand over a complex subsystem.

Multiple specialized facades

When a subsystem grows large, a single facade risks turning into a "God Object" with hundreds of methods. The solution is creating multiple specialized facades:

• OrderCheckoutFacade (cart checkout, payments, reservations)
• OrderReturnsFacade (reverse logistics, refund approvals, restock)
• OrderReportingFacade (aggregation, ledger reconciliation, analytics)

Where you've already used it

• Spring JdbcTemplate: A classic facade over JDBC's verbose Connection, PreparedStatement, ResultSet, and checked SQLException handling.
• jQuery $.ajax() / Modern fetch(): High-level facade over lower-level XMLHttpRequest, HTTP headers, MIME types, and streaming buffers.
• Operating System System Calls: open(), read(), write() act as facades over disk controllers, block drivers, cache pages, and inode metadata.
• Microservice API Gateways: Acts as a network-level facade aggregating data from 10+ microservices into a single consolidated payload for mobile clients.

Pros and cons

When not to use it

Do not introduce a Facade when a subsystem only contains one or two simple classes that are already easy to use. Wrapping a single simple service in an unnecessary facade layer adds boilerplate without reducing complexity.

Related patterns

Interview questions

How does Facade differ from Mediator? Facade provides unidirectional abstraction over a subsystem; the subsystem classes do not know the facade exists. Mediator coordinates bidirectional peer-to-peer communication among colleague objects, with colleagues actively knowing and calling the mediator.

Does a Facade prevent clients from accessing subsystem classes directly? No. A Facade provides a convenient default path for the majority of use cases, but it does not encapsulate or hide subsystem classes from power users who need granular configuration.

When does a Facade become an anti-pattern? When it becomes a monolithic God Object that attempts to orchestrate every operation in an enterprise, violating the Single Responsibility Principle. When this happens, split it into multiple domain-focused facades.

Can a system have multiple facades over the same subsystem? Yes. You can provide distinct facades tailored to different client personas (e.g., a CustomerFacingCheckoutFacade vs an AdminManualOrderFacade).