Facade Pattern
Provide a unified, higher-level interface to a complex subsystem while keeping subsystem coordination behind a simpler entry point.
Concept Overview
The Facade pattern provides a unified, higher-level interface to a set of interfaces in a subsystem. It makes a complex subsystem easier to use by hiding internal coordination from clients. A facade does not need to add new functionality; it offers a simpler way to invoke existing subsystem capabilities. The supplied infographic demonstrates a HomeTheaterFacade coordinating a video player, audio system and projector.
1. The problem: a client coordinates too many subsystem objects
A client that wants to play a movie may need to turn on a projector, select an input, configure audio volume, set a video source and start playback. Each subsystem has its own API and ordering requirements. If every client repeats that sequence, clients become coupled to internal subsystem details and changes must be repeated across call sites.
2. Give clients a higher-level operation
A HomeTheaterFacade can expose playMovie(movie) and endMovie() operations. Internally it calls the projector, audio system and video player in the required order. The client interacts with the facade rather than coordinating every subsystem directly. The subsystem objects still exist and can remain accessible for advanced use cases where clients genuinely need lower-level control.
final class HomeTheaterFacade {
private final VideoPlayer video;
private final AudioSystem audio;
private final Projector projector;
HomeTheaterFacade(VideoPlayer video, AudioSystem audio, Projector projector) {
this.video = video;
this.audio = audio;
this.projector = projector;
}
void playMovie(String movie) {
projector.on();
projector.setInput("HDMI");
audio.setVolume(50);
video.setVideo(movie);
video.play();
}
}3. Participants and responsibilities
The Facade knows how to coordinate the subsystem classes. Subsystem classes implement the underlying operations and generally do not need to know about the facade. The Client uses the simplified entry point for common workflows. This dependency direction helps keep subsystem logic independent from the facade and prevents the facade from becoming a replacement for the subsystem itself.
4. Facade does not mean blocking direct access
A facade simplifies the common path; it does not necessarily forbid clients from using subsystem classes directly. Some systems intentionally expose both a high-level API and lower-level APIs for advanced operations. The facade should avoid accumulating unrelated business rules or turning into a giant service object. Its responsibility is coordination and a simplified interface for a related subsystem.
5. When to use Facade
Use Facade when a subsystem is complex, several classes must be called in a particular sequence, or a client should depend on a simpler integration boundary. It can simplify application services around payment providers, media systems, document conversion or legacy libraries. It is less useful when the underlying API is already simple or when a facade would only forward every method without reducing coupling or complexity.
Key Takeaways
- ✓Facade provides one higher-level interface to a set of subsystem operations.
- ✓It simplifies client usage without needing to add new subsystem functionality.
- ✓Subsystems should remain independent of the facade.
- ✓Keep the facade cohesive and avoid turning it into an all-purpose service.