Facade
A facade exposes a small use-case operation over several collaborating components. It simplifies a client’s workflow while leaving the subsystem’s responsibilities intact.
What you’ll understand
- A facade exposes a small use-case operation over several collaborating components. It simplifies a client’s workflow while leaving the subsystem’s responsibilities intact.
- CheckoutFacade sequences stock validation, payment, and inventory update as one local use case.
- Evaluate the tradeoff: A facade does not automatically provide transactions or retries. Keep complex domain rules in their responsible components rather than turning the facade into a universal service.
Useful first: Classes and Objects
The idea and when to recognize it
A facade exposes a small use-case operation over several collaborating components. It simplifies a client’s workflow while leaving the subsystem’s responsibilities intact.
- Requirement: Checkout must validate stock before charging and reserving an item.
- Change to anticipate: Offer one placeOrder operation so callers cannot forget the stock check or charge a sold-out item.
- Design goal: CheckoutFacade sequences stock validation, payment, and inventory update as one local use case.
Start with the concrete problem
Checkout must validate stock before charging and reserving an item.
Offer one placeOrder operation so callers cannot forget the stock check or charge a sold-out item.
| Direct implementation | Revised design |
|---|---|
| Charging before checking stock creates a paid order that cannot be fulfilled. | CheckoutFacade sequences stock validation, payment, and inventory update as one local use case. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | A facade does not automatically provide transactions or retries. Keep complex domain rules in their responsible components rather than turning the facade into a universal service. |
Responsibilities and contracts
CheckoutFacade sequences stock validation, payment, and inventory update as one local use case.
- CheckoutFacade: Coordinates one use case. Public operations: placeOrder()
- Inventory: Checks and reserves stock. Public operations: reserve()
- Payment: Records accepted charges. Public operations: charge()
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A media-export facade can coordinate rendering, encoding, and writing through a single export operation.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
A facade does not automatically provide transactions or retries. Keep complex domain rules in their responsible components rather than turning the facade into a universal service.
Common mistake: Charging before checking stock creates a paid order that cannot be fulfilled.
- Explain the choice: CheckoutFacade sequences stock validation, payment, and inventory update as one local use case.
- Challenge your choice: A facade does not automatically provide transactions or retries. Keep complex domain rules in their responsible components rather than turning the facade into a universal service.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…