Facade

One object that knows the subsystem so you don't have to

A facade is structurally the simplest of all patterns. It is just a class that holds references to the subsystem objects and orchestrates them inside a few high-level methods. There is no clever inheritance, no special interface — only delegation in the right order:

• It holds the parts — the facade keeps a reference to each subsystem object (amp, dvd, screen, lights, projector).
• It knows the choreography — the correct order of calls, the right settings, the cleanup. That knowledge lives in one place instead of being copy-pasted into every caller.
• It exposes the common cases — one method per everyday task: watchMovie(), endMovie(). Rare or advanced needs can still go straight to the parts.

class HomeTheaterFacade {
  constructor(
    private amp: Amplifier,
    private dvd: DvdPlayer,
    private screen: Screen,
    private lights: Lights,
    private projector: Projector,
  ) {}

  watchMovie(film: string): void {   // one call — six steps, right order
    this.amp.on();
    this.dvd.on();
    this.screen.down();
    this.lights.dim(10);
    this.projector.on();
    this.dvd.play(film);
  }

  endMovie(): void {                 // and one call to undo it all
    this.dvd.stop();
    this.projector.off();
    this.lights.on();
    this.screen.up();
    this.dvd.off();
    this.amp.off();
  }
}

Notice what the facade does not do. It does not forbid direct access — if a power user wants to turn the amplifier up mid-movie, amp.setVolume(11) still works. It does not add new behaviour of its own — every line inside watchMovie() is a plain call to a subsystem the caller could have made. Its only job is to reduce what callers must know: from six classes and a fragile order down to one class and one method. That is [[coupling-and-cohesion]] in action — clients are coupled to one small facade instead of six churning subsystems — and it is the friendliest way to honour the [[law-of-demeter]]: callers talk to one near neighbour instead of reaching through a chain of strangers.

Facade vs Adapter — easy to mix up, easy to separate

Both patterns are 'a class in front of another class', so beginners blur them. The test is why the wrapper exists. An [[adapter]] changes an interface so it matches what some caller already expects — usually wrapping one object, converting calls one-for-one. A facade simplifies many interfaces into one — wrapping a whole subsystem and collapsing a multi-step workflow into a single friendly method. Adapter is about fit; Facade is about simplicity.

Reach for a facade when the subsystem is bigger than the task

• A complex subsystem with a simple common case — most callers want watchMovie(), not six device APIs. Give the 90% case a one-method door and let the 10% go direct.
• Layering — give each layer of your system one entry point. Controllers call OrderService, not the payment gateway, the inventory table, and the mailer directly. The facade is the layer boundary.
• Decoupling clients from subsystem churn — when the parts behind the facade get replaced (new payment provider, new DVD-turned-streaming source), only the facade changes. Every client keeps calling the same simple method.

When NOT to use it

• Don't force every call through it — a facade is a convenience, not a checkpoint. If advanced callers need the amplifier's fine controls, let them have the amplifier.
• Beware the god-object facade — a facade that mirrors every method of every subsystem class has simplified nothing; it's just a second copy of the API that must be kept in sync. Expose the few high-level tasks, not the whole surface.
• Skip it when the subsystem is already simple — wrapping one small class in a facade adds a layer with no payoff. One door in front of one door is just a hallway.