Abstraction
Abstraction exposes the essential operation and keeps the implementation mechanism behind a boundary. It lets a caller explain what it needs without knowing the steps used to provide it.
What you’ll understand
- Abstraction exposes the essential operation and keeps the implementation mechanism behind a boundary. It lets a caller explain what it needs without knowing the steps used to provide it.
- Checkout asks a ShippingPolicy for fee() and adds the result to the item total.
- Evaluate the tradeoff: An abstraction is useful when the hidden decision can vary independently. Adding a wrapper for a value that never varies can make navigation harder without protecting a real boundary.
Useful first: Classes and Objects
The idea and when to recognize it
Abstraction exposes the essential operation and keeps the implementation mechanism behind a boundary. It lets a caller explain what it needs without knowing the steps used to provide it.
- Requirement: A checkout needs a total including a shipping fee, but it should not know how a carrier selects a route or rate.
- Change to anticipate: Allow standard and express shipping policies to change their fees without changing checkout arithmetic.
- Design goal: Checkout asks a ShippingPolicy for fee() and adds the result to the item total.
Start with the concrete problem
A checkout needs a total including a shipping fee, but it should not know how a carrier selects a route or rate.
Allow standard and express shipping policies to change their fees without changing checkout arithmetic.
| Direct implementation | Revised design |
|---|---|
| Copying a carrier’s fee calculation into checkout exposes details that must change together. | Checkout asks a ShippingPolicy for fee() and adds the result to the item total. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | An abstraction is useful when the hidden decision can vary independently. Adding a wrapper for a value that never varies can make navigation harder without protecting a real boundary. |
Responsibilities and contracts
Checkout asks a ShippingPolicy for fee() and adds the result to the item total.
- Checkout: Combines prices through a stable operation. Public operations: total(items)
- ShippingPolicy: Hides fee selection. Public operations: fee()
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 database client can request save(record) without knowing how connection pooling or statement preparation works.
- 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
An abstraction is useful when the hidden decision can vary independently. Adding a wrapper for a value that never varies can make navigation harder without protecting a real boundary.
Common mistake: Copying a carrier’s fee calculation into checkout exposes details that must change together.
- Explain the choice: Checkout asks a ShippingPolicy for fee() and adds the result to the item total.
- Challenge your choice: An abstraction is useful when the hidden decision can vary independently. Adding a wrapper for a value that never varies can make navigation harder without protecting a real boundary.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…