Design Patterns interview question · Most asked
Scenario: your checkout supports card and PayPal, and the business adds a new payment provider every quarter. How would you design it?
Summary
Use Strategy: a PaymentMethod interface with one implementation per provider, chosen through a lookup table or factory from the customer's choice. Wrap each vendor SDK in an Adapter so provider quirks stay out of checkout. New providers become new classes plus a registration line.
Longer Answer
Checkout depends only on PaymentMethod.charge(). Each provider's adapter handles units, idempotency keys, error mapping and webhooks for that vendor. Tests use a fake payment method. Selection lives in one place (a map from method name to implementation), so no if/else grows in checkout.
Key Points
- Strategy for interchangeable providers.
- Adapter per vendor SDK.
- Lookup table/factory for selection.
- Checkout unchanged when providers are added.
Deep dive: Design Patterns, Explained Simply: Capstone: Refactor a Tangled Checkout
Explanation
What interviewers look for
Strategy + Adapter combination and Open/Closed reasoning.
Follow-up questions
- How would you handle provider-specific refunds?
- Where does idempotency belong?
More most-asked Design Patterns questions
- What problem does the Builder pattern solve? Show an example.
- Explain the SOLID principles.
- What is a design pattern, and why are they useful?
- What is the difference between dependency inversion, dependency injection and inversion of control?
- Why is composition often preferred over inheritance?
- What is dependency injection, and what forms does it take?
- Explain the Factory Method pattern and how it differs from a simple factory.
- How do you implement a Singleton, and why is it often considered an anti-pattern?