Adapter & Facade

Two structural patterns are your best friends when dealing with code you can't or shouldn't change - legacy subsystems and third-party libraries. Adapter makes an incompatible interface fit the one your code expects. Facade puts a simple, purpose-built front on a complicated subsystem. Both let you wrap rather than rewrite - exactly the evolutionary approach this path champions.

Adapter: making a square peg fit

You depend on an interface; a class you can't modify offers a different one. An Adapter sits between them, translating calls. ledger-legacy wants everything to implement its domain ReportSender, but a new third-party SMS gateway exposes dispatchTextMessage(number, body):

interface ReportSender { void send(Report r); }          // what our code expects

class TwilioGateway {                                     // third-party, can't change
    void dispatchTextMessage(String number, String body) { ... }
}

class TwilioReportSenderAdapter implements ReportSender { // the ADAPTER
    private final TwilioGateway twilio;
    private final String recipient;
    public void send(Report r) {                          // translate our call...
        twilio.dispatchTextMessage(recipient, r.asShortText());   // ...into theirs
    }
}

Now the third-party class plugs into our world through the adapter, and our domain code stays blissfully unaware of Twilio. Adapter is the standard way to keep vendor libraries at the edge (a preview of hexagonal architecture's "adapters"): the messy foreign interface is quarantined in one wrapper, and swapping vendors means writing one new adapter.

Facade: a simple door to a complex building

A Facade provides a simplified interface to a complicated subsystem. The LedgerManager is a tangle of parsing, fee calculation, persistence, and formatting; a client that just wants "import this file and give me a summary" shouldn't have to orchestrate all of it:

class LedgerFacade {                                     // one simple entry point
    private final CsvTransactionParser parser;
    private final FeeCalculator fees;
    private final TransactionRepository repo;
    private final ReportFormatter formatter;

    public ImportSummary importFile(Path csv) {          // hides the whole dance
        var txns = parser.parseAll(csv);
        txns.forEach(t -> { t.applyFee(fees.calculate(t)); repo.save(t); });
        return formatter.summarize(txns);
    }
}

The subsystem classes still exist and can be used directly by code that needs fine control; the facade just offers a convenient front for the common case. It reduces coupling - callers depend on the small facade, not on five collaborators and their wiring.

Adapter vs. Facade

They both wrap, so the distinction matters:

• Adapter changes an interface to match an existing expected one - the shapes are dictated by both sides, and the goal is compatibility. Usually wraps one class.
• Facade invents a new, simpler interface over a subsystem - the shape is whatever's convenient, and the goal is simplification. Usually fronts many classes.

Adapter answers "this doesn't fit"; Facade answers "this is too complicated."