Facade Pattern
Provide a simplified interface to a complex subsystem. A Facade reduces the complexity of using a subsystem and decouples the client from subsystem internals.
Facade = a hotel concierge. You say 'plan my evening' and they call the restaurant, the theatre, and the taxi company behind the scenes. You never dial three numbers yourself — one friendly face handles the chaos.
Facade does not eliminate the subsystem — it hides it. The subsystem classes still exist and can be used directly for advanced use cases. Common examples: a VideoConverter facade that hides codec selection, audio stream management, and format negotiation behind a single convert(file, format) method; a Home Theatre facade that hides amplifier, DVDPlayer, Projector, and Screen behind watchMovie() and endMovie().
Facade vs Adapter: Adapter makes an incompatible interface compatible (one-to-one); Facade simplifies many interfaces into one (many-to-one). Facade vs Mediator: Facade is a one-way simplification (clients call the facade; the facade orchestrates the subsystem); Mediator is a two-way hub where subsystem components communicate through the mediator, and the mediator may call back to them. Facade is appropriate for layered architecture: each layer exposes a Facade to the layer above, hiding internal complexity. The Facade becomes the API boundary. A Facade that starts managing state or adding significant business logic has become a service or mediator — the line is worth discussing in interviews.
Facade is the pattern for API design within a layered system. My OrderFacade exposes placeOrder(cart, customer) — behind the scenes it orchestrates InventoryService, PricingEngine, PaymentGateway, NotificationService, and AuditLog. The client (REST controller) calls one method. The subsystem components can still be used independently for admin workflows. I distinguish Facade from Mediator: Facade is a one-directional simplification — the client calls the facade, which calls the subsystem; the subsystem never calls the facade back.
Facade can grow into a god class if it accretes business logic rather than pure delegation. Monitor facade method count and complexity. If the facade is making decisions (not just orchestrating), refactor the decisions back into the appropriate subsystem.