Facade
The problem
Checking out involves three subsystems in a strict sequence: verify stock, reserve it, charge the customer, book the courier. If every caller (web checkout, phone orders, the till in the physical shop) orchestrates this by hand, the sequence is duplicated everywhere – and one caller forgetting the stock check before charging is a refund waiting to happen.
The pattern
A facade offers one intention-sized method and keeps the subsystem choreography inside:
CheckoutSummary summary = checkout.checkout(alice, books, "1 High Street");
The subsystems still exist, are individually testable, and remain available to callers with genuinely special needs – the facade adds a simple front door, it doesn’t lock the side doors.
Benefits
- One correct sequence – the stock-check-before-charge ordering is written once; callers can’t get it wrong.
- Reduced coupling – callers depend on one class, not three; subsystems can be refactored behind the facade freely.
- Readable client code –
checkout(...)says what happens; the how is a detail.
Seen in the wild
java.nio.file.Files (facade over channels, charsets, attribute views), Spring’s JdbcTemplate
(facade over connection/statement/result-set handling), SLF4J’s LoggerFactory.
Implementation
CheckoutFacade– the front door holding the one correct sequence.InventoryService,PaymentService,ShippingService– the subsystems it orchestrates.CheckoutSummary– the result type.