Explain the Facade design pattern with use cases

• Facade – a structural design pattern that provides a single, simplified, higher-level interface to a complex subsystem of many classes.
• Delegation – the facade holds references to subsystem classes and calls them in the correct order; it adds no business logic of its own.
• Reduced coupling – clients depend only on the facade's stable interface, not on the volatile internals of the subsystem.
• Non-intrusive – the facade offers the easy path for common cases; advanced callers can still use subsystem classes directly.
• Thin coordinator – if the facade starts holding real rules, it degrades into a God object.

What is the Facade pattern?

A subsystem often grows into many collaborating classes, each doing part of a workflow. If every client has to know all those classes and the right sequence, the client becomes tightly coupled to the subsystem. The facade solves this by exposing a small number of coarse-grained methods that represent what clients actually want to do.

How does delegation work inside a facade?

The facade holds references to subsystem classes and calls them in the correct order.

package com.bank.facade;

import com.bank.service.CreditScoreService;
import com.bank.service.IncomeVerificationService;
import com.bank.service.PropertyValuationService;
import com.bank.service.LegalTitleService;
import com.bank.service.DisbursementService;
import java.math.BigDecimal;

public class LoanApprovalFacade {

    private final CreditScoreService creditScore;
    private final IncomeVerificationService income;
    private final PropertyValuationService property;
    private final LegalTitleService legal;
    private final DisbursementService disbursement;

    public LoanApprovalFacade(CreditScoreService creditScore,
                              IncomeVerificationService income,
                              PropertyValuationService property,
                              LegalTitleService legal,
                              DisbursementService disbursement) {
        this.creditScore = creditScore;
        this.income = income;
        this.property = property;
        this.legal = legal;
        this.disbursement = disbursement;
    }

    public LoanDecision approveHomeLoan(String customerId, BigDecimal amount) {
        int score = creditScore.fetch(customerId);
        if (score < 700) return LoanDecision.rejected("Credit score below 700");

        boolean incomeOk = income.verify(customerId, amount);
        if (!incomeOk) return LoanDecision.rejected("Income insufficient");

        BigDecimal valuation = property.valuate(customerId);
        boolean titleClear = legal.checkTitle(customerId);
        if (!titleClear) return LoanDecision.rejected("Title not clear");

        disbursement.disburse(customerId, amount);
        return LoanDecision.approved(amount, valuation);
    }
}

Expected output:
LoanApprovalFacade: approveHomeLoan(CUST-1001, 5000000.00)
CreditScoreService: score=750
IncomeVerificationService: verified=true
PropertyValuationService: value=7500000.00
LegalTitleService: clear=true
DisbursementService: disbursed 5000000.00
Result: APPROVED

How is the Facade different from Adapter, Mediator, and Proxy?

| Pattern | Purpose | Direction |
|---|---|---|
| Facade | Simplifies a complex subsystem into one interface | One-way; subsystem does not know the facade |
| Adapter | Converts one interface to another so incompatible things fit | Wraps one object |
| Mediator | Coordinates two-way interaction between peers | Bidirectional; peers talk back to mediator |
| Proxy | Stands in for one object to control access, caching, laziness | Wraps one object, same interface |

Why must the facade stay thin?

If the facade starts holding real business rules it becomes a God object violating single responsibility. The real logic stays in the subsystem classes; the facade only orchestrates.

// WRONG: facade holds business logic
public LoanDecision approve(String customerId, BigDecimal amount) {
    // calculating EMI, applying interest rates, checking blacklists HERE
    // turns the facade into a God object
}

// CORRECT: facade delegates to specialists
public LoanDecision approve(String customerId, BigDecimal amount) {
    if (creditScore.fetch(customerId) < 700) return rejected();
    // each specialist holds its own logic
}

What are typical use cases?

• A @Service class in Spring that orchestrates repositories, validators, and external clients to fulfil one business operation.
• Wrapping a complicated third-party library so the rest of the code calls a simple in-house interface.
• One onboardCustomer or processLoan method that coordinates many steps.
• An API Gateway presenting one endpoint that fans out to many internal services.

How does a facade relate to microservices?

At the network level, an API Gateway is essentially a facade: it presents one entry point, coordinates calls to multiple backend services, and hides the internal topology from clients.

What should a senior engineer know?

• The facade is an excellent place to apply a single transaction boundary, consistent logging, and uniform error translation for a whole workflow.
• You can have several facades over the same subsystem for different client needs.
• The pattern shines when onboarding new developers, who can accomplish common tasks through the facade without learning the entire subsystem.
• In Spring, constructor injection makes the delegation explicit and testable.

What are common interview follow-up questions?

• Can a facade call another facade? (Yes, but keep the depth shallow to avoid hidden complexity.)
• How do you test a facade? (Unit test with mocked subsystem classes; integration test the full chain.)
• When should you NOT use a facade? (When there is no subsystem complexity to hide; adding a facade around one class is pointless indirection.)