🪞Facade Pattern

Provide a unified interface to a set of interfaces in a subsystem — define a higher-level interface that makes the subsystem easier to use.

📌 Key IdeaWrap messy collaboration between many classes behind one readable method (placeOrder). Does not hide subsystem from everyone — only gives convenience for typical workflows. Subsystem classes still exist for power users.

🖼

Visual

🪞 One call hides many

  class OrderFacade {
    void place(Order o) {
        inventory.reserve(o);
        payment.charge(o);
        email.sendConfirmation(o);
    }
  }

Facade orchestrates; doesn't rob subsystem of flexibility if callers need lower-level APIs.

✅

When to Use

Subsystem has many moving parts — newcomers need a guided workflow.
You want layered APIs: simple facade for 80%, expert APIs exposed separately.
Legacy bundle — stabilise integration behind one class while refactoring internals.

🚫

When NOT to Use

Subsystem already has one clear entry — facade is redundant.
You mistake facade for only allowed API — avoid trapping advanced use cases.

🚨

Anti-Pattern (What NOT to Do)

Controller wires five services inlineBadjava

void checkout(Cart c) {
    inventory.reserve(c);
    pricing.apply(c);
    payment.charge(c.getTotal());
    warehouse.pick(c);
    email.sendInvoice(c.getUser());
}

Every caller duplicates orchestration; sequence drift across endpoints.

✅

The Right Way

Facade — one workflow entryGoodjava

class CheckoutFacade {
    CheckoutFacade(Inventory inv, Payment pay, Mailer mail) { ... }

    void complete(Cart c) {
        inv.reserve(c);
        pay.charge(c);
        mail.invoice(c.getUser());
    }
}

Controllers call complete; subsystem classes stay injectable / testable.

⚖️

Pros & Cons

👍 Pros

Reduces learning curve and coupling for common paths.
Shields clients from churn inside subsystem (refactor behind facade).

👎 Cons

Facade can become a god object if it keeps absorbing unrelated workflows.
Wrong abstraction hides needed knobs — balance simplicity vs control.

🔀

Common Confusions Cleared Up

Facade vs Adapter

Adapter bridges two incompatible interfaces (often 1:1). Facade simplifies many classes working together — broader orchestration, usually same conceptual domain.

Facade vs Mediator

Both coordinate. Mediator stops colleagues from talking directly — central hub. Facade is one-way convenience from client into subsystem; peers may still call each other beneath.

🎤

Interview Q&A

🔮

Likely Follow-up Questions

When would you split one facade into several (per bounded context)?

🧾

Quick Cheat Sheet

IntentSimple API over complex subsystem.

vs AdapterMany→one convenience vs interface bridge.

RiskFat facade / god service.

🔗