Facade pattern

Introduction

The Facade pattern gives clients a small, workflow-oriented interface to a subsystem made of several collaborating classes. It coordinates existing operations without requiring callers to know their order or setup.

TL;DR / mental model: Treat a facade as the front desk for a subsystem: callers ask for a useful outcome, and the facade coordinates the specialists behind it. The subsystem can still be available for advanced cases.

Problem and Context

Your team builds a video conversion feature. Converting a video file requires five separate subsystems: read the source file, detect the codec, extract audio, encode the video in the target format, and write the output. Every caller that needs to convert a video must know the right classes, the right method order, and the right error handling.

Three callers duplicate this sequence. When the team adds watermarking as step 3.5, all three callers need updating. When the codec detection API changes, all three break. The coupling is not to one class but to an entire orchestration sequence.

When It Helps

A facade helps when multiple callers repeat a multi-step workflow or when a subsystem exposes more classes and ordering rules than most callers should need to understand. It adds less value when one caller needs every low-level option or the subsystem already has a clear, cohesive API.

Here is what changes when you apply the Facade pattern.

---

Participants and Structure

Participants

• Facade: exposes a workflow-oriented operation such as convert() and coordinates the subsystem calls.
• Subsystem classes: perform the specialized work; they do not need to know about the facade.
• Client: uses the facade for the common path and can use subsystem classes directly when it needs finer control.

VideoConversionFacade is the single entry point that hides five subsystem classes. Callers call convert() and get a file back. They never import, instantiate, or orchestrate the subsystem classes directly. The facade does not add new functionality; it just makes existing functionality easier to use correctly.

---

Idiomatic Example and Implementation Notes

The facade wraps the subsystem by composing its classes as private fields. Each public method on the facade orchestrates the right sequence of subsystem calls. Callers never see the subsystem internals.

A useful trigger is repeated, multi-step orchestration across callers. If only one caller uses a subsystem, a facade may add indirection without enough benefit.