Facade Pattern: simplifying complex systems

The Facade pattern is a simple interface that hides the complexity of a subsystem.

In other words, instead of forcing the client to talk to twenty different classes, we give them a more convenient entry point. Inside there may be validations, services, repositories, APIs, caches, and other gadgets. But from the outside, its use is reduced to a few clear operations.

The problem

Imagine we have an application for processing orders. To complete an order we need to:

If each controller, screen or service has to coordinate all of this manually, we’ll soon have duplicated and tightly coupled code everywhere.

validator.Validate(order);
stock.Reserve(order);
taxes.Calculate(order);
payments.Charge(order);
invoices.Generate(order);
emails.SendConfirmation(order);

The client knows too many things. And when a process changes, every place that wired it up manually must be reviewed.

The Facade idea

With Facade, we create a class that represents the high-level operation. In our case, something like OrderProcessor.

public class OrderProcessor
{
    private readonly OrderValidator _validator;
    private readonly StockService _stock;
    private readonly TaxCalculator _taxes;
    private readonly PaymentGateway _payments;
    private readonly InvoiceGenerator _invoices;
    private readonly EmailService _emails;

    public OrderProcessor(
        OrderValidator validator,
        StockService stock,
        TaxCalculator taxes,
        PaymentGateway payments,
        InvoiceGenerator invoices,
        EmailService emails)
    {
        _validator = validator;
        _stock = stock;
        _taxes = taxes;
        _payments = payments;
        _invoices = invoices;
        _emails = emails;
    }

    public void Process(Order order)
    {
        _validator.Validate(order);
        _stock.Reserve(order);
        _taxes.Calculate(order);
        _payments.Charge(order);
        _invoices.Generate(order);
        _emails.SendConfirmation(order);
    }
}

Now the client only needs to know about one class:

orderProcessor.Process(order);

The complexity still exists, of course. But it’s encapsulated in one specific point, with a name that expresses the intent of the use case.

What it achieves

Facade reduces coupling between the client and the subsystem. The client no longer needs to know which classes participate, in what order they are called, or what technical details lie behind them.

This has several advantages:

• Cleaner client code, because it works with high-level operations.
• Fewer direct dependencies, because not everyone knows everyone else.
• More localized changes, because the flow lives in a concrete class.
• Better readability, because Process(order) communicates the intent better than six isolated calls.

Facade is not about hiding junk

A common mistake is to use Facade to cover up a chaotic design without fixing anything underneath. This can ease external use, but it doesn’t turn a bad design into a good one.

If the subsystem is poorly divided, with mixed responsibilities and circular dependencies, Facade can serve as a temporary entry point. But it shouldn’t be an excuse to leave the internals tangled.

The facade simplifies access. It doesn’t perform miracles.

Facade vs Adapter

Facade and Adapter are similar because both put a class in front of other classes. The intent, however, is different.

Adapter changes how you talk to something. Facade reduces the number of things you have to talk to.