Facade

Intuition

Think of a modern TV setup:

• TV

• Sound system

• Set‑top box or streaming device

• Game console

• Lights, maybe blinds

To “watch a movie”, you might need to:

• Turn on the TV

• Switch to HDMI input

• Turn on the sound system

• Set volume level

• Dim lights

A remote with a single “Movie” button that does all these steps for you is acting like a facade: it hides the messy sequence of operations behind a simple interface.

That is the core idea of the Facade Design Pattern.

Intent of the Facade pattern

The core intent:

Provide a simple, unified interface to a set of interfaces in a subsystem, making it easier for clients to use.

Key ideas:

• The system internally has multiple classes and complex interactions.

• Clients often need just a few common workflows.

• A facade class exposes simple methods like startMovie()  placeOrder(), and inside those methods, it coordinates multiple subsystem objects.

• This reduces coupling: clients depend on the facade, not on many internal classes.

Facade does not replace the subsystem; it sits “in front” of it as an easier entry point.

Basic structure

Typical roles:

• Subsystem classes

  • Many classes that implement the actual functionality.

  • They may be complex, with many methods and interactions.

• Facade

  • Provides high‑level methods that represent common use cases.

  • Internally creates or uses subsystem objects and calls their methods in the correct order.

  • Clients call the facade instead of talking directly to the subsystem.

Clients can still access subsystem classes directly if they need advanced control, but most client code uses the facade.

C++ example: Home theater facade

Subsystem classes

A client wanting to “watch a movie” might need to orchestrate all of these in the right order.

Facade class

Using the facade

The client now calls one or two simple methods on the facade, instead of knowing about all the subsystem details.

Why use a Facade?

Benefits:

• Simpler usage

  • Client code becomes much easier to read and write since it calls a small, clear API.

• Reduced coupling

  • Clients depend mainly on the facade.

  • Changes inside the subsystem (new classes, new sequences) can often be handled by updating only the facade.

• Better separation of concerns

  • Subsystems focus on doing their specific jobs.

  • The facade focuses on orchestrating them for common workflows.

Facades are especially useful in Low Level Design when the underlying logic is comple,x but the main use cases can be expressed in a few verbs like placeOrder, bookTicket, or startBackup.

Facade vs Adapter vs Decorator

These patterns can look somewhat similar, but their goals differ:

• Facade

  • Simplifies usage of a complex subsystem.

  • Provides a higher‑level interface.

  • The subsystem and facade are usually designed to work together.

• Adapter

  • Makes an existing interface look like another one that clients expect.

  • Solves compatibility problems between mismatched interfaces.

• Decorator

  • Adds behavior to individual objects dynamically by wrapping them.

  • The interface usually stays the same; behavior changes.

A quick mental shortcut:

• If the issue is “too many classes and methods” → Facade.

• If the issue is “wrong shape of interface” → Adapter.

• If the issue is “need extra behavior around an object” → Decorator.

When to use the Facade pattern

Good situations for a facade:

• A module or library has many classes and a complex API, and you want a simplified entry point for most clients.

• You want to layer your system: higher layers talk to lower layers through facades, not directly to many classes.

• You want to shield client code from frequent changes inside a subsystem.

Maybe not worth it when:

• The subsystem is small and simple; a facade might just add an unnecessary layer.

• Clients mostly need fine‑grained control over subsystem classes rather than simple workflows.

In practice, many large systems naturally evolve facades: “service” classes or “manager” classes that expose core operations of a complex domain.