The Facade Pattern - One Simple Door to Complexity

The Facade Pattern

The Facade pattern hides a complex subsystem behind one simple interface. You give callers a single, friendly class that internally coordinates dozens of moving parts. This is probably the most used design pattern in real projects because it makes awkward systems pleasant to call.

The Problem: Too Many Parts

Placing an online order touches inventory, payments, shipping, and notifications. If every caller must wire those four services together in the right order, the logic gets repeated everywhere and breaks if one service changes. A facade gathers that wiring into one place.

+-----------------------+
|        Client         |
+-----------------------+
          |
          >  placeOrder(order)
          |
+-----------------------+
|     OrderFacade       |
+-----------------------+
   |        |        |
   >        >        >
+--------+ +--------+ +---------+
|Checkout| |Shipping| |Notifier  |
|Service | |Service | |Service   |
+--------+ +--------+ +---------+

The client sees one method. The facade sees three services and coordinates them.

Without a Facade

Here is the fiddly code callers would repeat.

InventoryService  inv  = new InventoryService();
PaymentService    pay  = new PaymentService();
ShippingService   ship = new ShippingService();
NotificationService note = new NotificationService();

inv.reserve(item);
pay.charge(customer, amount);
ship.schedule(item, address);
note.send("Order received");

Every caller must know the order and every service. One schema change ripples through all of them.

Adding the Facade

The facade encapsulates the sequence once.

public class OrderFacade {
    private InventoryService inv;
    private PaymentService pay;
    private ShippingService ship;
    private NotificationService note;

    public void placeOrder(Item item, Customer c, Address a) {
        inv.reserve(item);
        pay.charge(c, item.price());
        ship.schedule(item, a);
        note.send("Order placed");
    }
}

OrderFacade facade = new OrderFacade();
facade.placeOrder(item, customer, address);

Walkthrough: placeOrder() runs the same four steps the manual callers ran. Callers now see a single method with ready-made defaults such as which service to notify and when. The subsystem classes stay public for advanced callers, but the everyday path goes through the facade.

A Real-World Case

ORM libraries are enormous facades. When you call session.save(entity), you never think about connection pooling, SQL statement preparation, transaction boundaries, or cache invalidation - one method triggers a whole hidden pipeline. A home theater remote is the same idea in hardware: one button press dims the lights, turns on the projector, and lowers the screen. The Facade does not add capability; it adds calm.

Key Points

• Facade provides a single simple interface over a complex subsystem.
• It reduces coupling: callers depend on one class, not ten.
• The subsystem remains available for power users who need more control.
• It collects commonly repeated sequences into one tested method.
• Do not confuse it with a mediator - a facade forwards requests, it does not choreograph peers.
• It is cheap to add and immediately improves readability.