intermediate
Abstraction
Model only the responsibilities a caller needs and leave storage, algorithms, or collaboration details behind the boundary.
Abstraction exposes only what a client needs—`PaymentGateway.charge(order)`—hiding tokenization, retries, and provider SDK details. Good abstractions match caller mental models and stay stable when implementation swaps (Stripe to Adyen).
Leaky abstractions force callers to know internals; oversized ones bundle unrelated responsibilities.
On interviews: sketch an interface for file storage usable by domain code without S3 types leaking upward.
Common pitfalls: abstractions named after vendors, interfaces that mirror one implementation exactly, and premature abstraction before second use case.
The trade-off is simpler call sites versus wrong seam that ossifies bad design.
Checklist:
- Model caller needs, not storage details.
- Keep abstraction surface minimal.
- Validate with a second implementation or test double.