The Facade Pattern gives client code one purposeful entry point into a complex subsystem. Instead of teaching every caller how to start an engine, turn on headlights, validate a request, or coordinate a library’s internal classes, a facade exposes the operation the caller actually needs. The result is not less capability in the subsystem; it is less coupling at its boundary.
What the Facade Design Pattern removes from client code
The Gang of Four describes the facade design pattern as a unified, higher-level interface to a set of interfaces in a subsystem. It is one of the structural design patterns: its job is to arrange access to existing parts, not to invent the parts’ behavior.
Without that boundary, a client can depend directly on many objects with unrelated interfaces. That makes the client harder to implement, change, test, and reuse because it must know both the sequence of calls and the details of each component. A facade concentrates that knowledge behind a simpler interface.
Think of a store operator who accepts a single request and coordinates ordering, payment, and delivery internally. The caller gets a clear conversation; the underlying systems can still do their specialized work.
How a facade routes work without owning the subsystem
A facade class offers convenient access to a focused slice of subsystem functionality. It knows where to send a client request and how to coordinate the moving parts, while the subsystem objects continue to work directly with one another.
- The client calls the facade rather than several subsystem objects.
- The facade delegates to the classes that perform the work.
- The subsystem classes do not need to know that the facade or client exists.
- Advanced callers can still use public subsystem functions when they need deeper control.
This reduces dependencies: a typical client references one facade object instead of many subsystem objects.
Implement a facade around one meaningful operation
Start with an operation that callers repeat and that requires them to coordinate several collaborators. The C++ example below turns a car-start sequence into one method. Car is the facade; Engine and Headlights remain focused subsystems.
class Engine {
public:
void Start();
};
class Headlights {
public:
void TurnOn();
};
class Car {
Engine engine;
Headlights headlights;
public:
void Start() {
engine.Start();
headlights.TurnOn();
}
};
// Client code:
// Car car; car.Start();The important design choice is the method boundary. Start() describes what the client wants, not the internal checklist it must perform. The facade should delegate and coordinate; if it accumulates unrelated business rules, it becomes a new source of complexity rather than a simplified interface.
Keep the interface narrow as the subsystem grows
Do not turn every subsystem method into a forwarding method. A facade is useful when it provides the small set of features clients actually need. If unrelated features begin to pile up, create multiple facades for distinct aspects of the system instead of one oversized entry point.
Read the UML structure in one glance
The UML relationship is deliberately one-way at the boundary: the client calls the facade, and the facade knows the subsystem classes. Those classes know neither the facade nor the client.
Client --uses--> Facade
| delegates to
+------------+-------------+
v v v
Subsystem A Subsystem B Subsystem CThe classic compiler example follows this shape. A Compiler facade starts compilation while coordinating Scanner, Parser, ProgramNode, BytecodeStream, and ProgramNodeBuilder.
Use a facade where a boundary makes change safer
Use this structural pattern when a subsystem has many interdependent classes, when its source is unavailable, or when callers need only a small part of a broad framework or library. A video-conversion library may offer extensive functionality, while an application needs only an encode(filename, format) operation. A facade can provide exactly that operation.
It is also practical at architecture boundaries. In a layered application, each layer can provide a facade to the layer above it. An API gateway or Backend for Frontend can likewise bundle complex service calls behind a simpler endpoint. In both cases, the boundary can simplify and protect access without making the services disappear.
Wrap third-party and legacy dependencies before they spread
A facade around a third-party library separates client code from that library’s implementation details. If the library changes or is replaced, the adaptation can stay in the facade rather than reach across the codebase. The same approach can put a stable boundary in front of tightly coupled legacy code while components behind it are replaced gradually.
SLF4J, the Simple Logging Facade for Java, is a concrete example: it abstracts java.util.logging, Logback, and Log4j behind a unified API.
Know the benefits and limits before you add one
| What a facade can improve | What it does not solve |
|---|---|
| Client readability: one call can replace a sequence of subsystem calls. | It does not remove the need for deeper access when a client needs advanced functions. |
| Maintenance: an operation and related validation can be centralized at the boundary. | It should not become a class coupled to every part of the application. |
| Testing: clients can be tested against a focused interface rather than a complex subsystem. | It cannot make a poorly separated subsystem cohesive by itself. |
| Dependency control: clients are decoupled from third-party implementation details. | It should not simply mirror every method and call that a subsystem already exposes. |
A facade is the wrong fit when callers need flexible, detailed control over the underlying system. Bypassing it is then legitimate. It is also a weak fit when it merely forwards most of a subsystem’s methods: that undersimplification adds a layer without reducing cognitive load.
Distinguish facade from nearby design patterns
A facade defines a new, simpler interface to existing objects, usually coordinating multiple objects behind it. An Adapter converts an existing interface into the interface a client expects, and it commonly wraps a single object. One class can be both an adapter and a facade if it converts and simplifies, but the two intentions remain different.
Mediator has a different role as well. A facade reveals existing functionality from a different perspective. A mediator adds new functionality by combining existing objects: its components know about and communicate with the mediator. Facade subsystem components do not need that relationship. If the real need is to hide construction of subsystem objects, Abstract Factory can be an alternative; a facade is typically used later, at runtime, to coordinate their use.
Avoid the myths that turn a facade into a God Object
“The facade must be the only way in”
No. The pattern can leave subsystem classes publicly accessible for clients that need deeper features. Its value is a convenient default path, not enforced isolation.
“The facade should contain all business logic”
No. A clean facade delegates to the subsystem. When a single class takes on too many responsibilities and becomes coupled to the whole application, it risks the God Class anti-pattern and violates single responsibility.
“One facade is always simpler than several”
No. Multiple facades can be clearer when they represent different parts of a large subsystem. Splitting them prevents a supposedly simple interface from becoming a catalog of unrelated operations.
Frequently Asked Questions
What is the Facade design pattern, and what problem does it solve?
It provides a unified, higher-level interface to a set of subsystem interfaces. It keeps clients from having to coordinate many objects with different interfaces directly.
How does the Facade Pattern work?
The client calls the facade, which delegates to and coordinates subsystem classes. Those classes do not need to know about the client or the facade.
How can a facade simplify a third-party library?
It can expose only the library operations an application needs. Client code then depends on the facade interface, so changes to the library can be handled at that boundary.
What are real-world examples of a facade?
SLF4J provides a unified logging API over several Java logging frameworks. A home-control app can also present one control surface for lighting, heating, and security cameras.
What is the facade pattern in Angular?
The pattern is not tied to a specific framework. In Angular as elsewhere, the idea is to place a focused interface in front of a complex set of collaborating parts so callers use a smaller, purpose-built boundary.