Everydayas Code

Facade Pattern: One Door into a Complex System

Facade offers a small task-oriented interface over a complicated subsystem, reducing the knowledge each caller needs for common workflows.

What is the Facade pattern?

The Facade pattern is a structural design pattern that provides one simplified, task-oriented interface to a complex subsystem. Instead of every caller learning which five objects to create and in which order to call them, the facade exposes methods named after what users actually want done — and orchestrates the machinery behind the scenes.

A good facade reduces required knowledge, not available power. The subsystem's full API stays reachable for the callers that need it; the facade just makes the common path short and safe. Compiler front-ends, SDK "client" classes, and most service-layer classes in web applications are facades whether or not anyone calls them that.

The logic, step by step

Problem

Callers must coordinate many subsystem objects in the correct sequence just to complete one ordinary task.

Rule

Expose a focused high-level operation that orchestrates subsystem details while leaving advanced APIs available when necessary.

Run
  1. CLIENT requests a complete outcome through one task-oriented method.
  2. FACADE coordinates validation, ordering, and subsystem interactions.
  3. SUBSYSTEMS perform specialized work without becoming client concerns.
Output

Common use cases become easier and safer without replacing the underlying subsystem capabilities.

Facade pattern example in TypeScript

TypeScript 
class VideoExporter {
  constructor(
    private encoder: Encoder,
    private muxer: Muxer,
    private metadata: MetadataWriter,
    private storage: Storage,
  ) {}

  // One task-oriented method replaces four coordinated calls.
  async exportMp4(timeline: Timeline, preset: 'web' | 'archive'): Promise<FileRef> {
    const settings = preset === 'web'
      ? { codec: 'h264', bitrate: 4_000_000 }
      : { codec: 'prores', bitrate: 80_000_000 };

    const video = await this.encoder.encode(timeline, settings);
    const container = this.muxer.mux(video, timeline.audioTracks);
    this.metadata.stamp(container, { createdAt: new Date(), preset });
    return this.storage.write(container);
  }
}

// Callers with ordinary needs stay one line long:
const file = await exporter.exportMp4(timeline, 'web');

// Power users can still reach encoder/muxer directly for exotic pipelines.
exportMp4 hides ordering, presets, and coordination. The subsystem classes remain public — the facade shortens the common path without locking the advanced ones.

Run it in the real world

A video export facade validates settings, starts rendering, writes metadata, and stores the file while advanced callers can still access lower-level tools.

When to use it — and when not to

Reach for Facade when

  • Completing an ordinary task requires coordinating several objects in a specific order.
  • You want a stable public surface over a subsystem that refactors frequently.
  • Layering: presenting a clean entry point per module keeps other modules from reaching into internals.

Skip it when

  • The subsystem is one or two calls — a facade would just rename them.
  • The facade starts accumulating business logic of its own; orchestration belongs in it, domain rules do not.

Adapter pattern — Facade defines a new simpler interface over many objects; Adapter reshapes one object to match an interface that already exists. Simplification versus compatibility.

Singleton pattern — Facades are frequently made singletons "for convenience" — resist it. One facade instance injected where needed gives the same ergonomics without global state.

Frequently asked questions

What is the difference between a Facade and an API?

Every facade is an API, but not every API is a facade. A facade specifically wraps an existing, more complex set of interfaces to offer a simpler view of the same capability — the complexity it hides is already there behind it.

Is a service layer the same as a Facade?

A service layer is facade-shaped: it gives controllers one entry point that orchestrates repositories and domain objects. The difference is that service layers usually also own transactions and application rules, which goes beyond pure facade duty.

When does a Facade become a god object?

When it stops delegating and starts deciding. Warning signs: the facade holds state, contains branching business rules, or has grown methods for every subsystem feature. A facade should read like a table of contents, not like the book.