# Design an Object-Oriented Shopping Cart Design the core objects and interfaces for a shopping cart. It must add, remove, and change item quantities; calculate a subtotal; apply independently evolving pricing adjustments; and expose a stable summary for checkout. Focus on responsibilities, invariants, and how new rules can be introduced without rewriting the cart. ### Constraints & Assumptions - Product IDs are stable, but display metadata may change outside the cart. - Monetary arithmetic uses an exact decimal or integer minor-unit type. - A cart line has a positive quantity and a captured unit price or pricing reference. - Inventory reservation and payment execution are outside the initial object boundary. - Promotions may reject or adjust selected lines but must be explainable. ### Clarifying Questions to Ask - Does the cart snapshot price or reprice on every read? - Can promotions stack, and in what order? - What happens when an item becomes unavailable? - Must the cart support concurrent updates from several devices? ### Part 1 - Domain model and invariants Define cart, line item, money, product/pricing reference, and summary objects. Identify which object owns quantity and subtotal invariants. #### What This Part Should Cover - Clear aggregate boundary and encapsulated mutation - Exact money handling - Stable identity separate from mutable display data - Invalid quantity and missing-line behavior ### Part 2 - Extensible pricing behavior Design a pricing or adjustment interface for coupons, item discounts, and future rules without adding conditionals throughout the cart. #### What This Part Should Cover - Pure, testable adjustment inputs and outputs - Deterministic ordering or combination policy - Structured explanation of adjustments - Versioning or snapshot decisions ### Part 3 - Persistence and testing Explain optimistic concurrency, idempotent commands, serialization, and tests for interacting changes. #### What This Part Should Cover - Cart version or compare-and-set updates - Retry-safe command identity - Unit and state-transition tests - Separation from inventory and payment workflows ```hint Keep calculation separate from mutation A pricing service can consume an immutable cart snapshot and return an explained price breakdown, leaving the cart responsible for item state. ``` ### What a Strong Answer Covers - Small objects with explicit ownership of cart invariants - Exact monetary calculations and clear price-snapshot semantics - Extensible, explainable pricing adjustments - Concurrency, idempotency, persistence, and interaction-focused tests ### Follow-up Questions 1. How would you handle two devices updating the same cart version? 2. Where should inventory reservation begin, and how is it released? 3. How would you reproduce an old order total after promotion rules change?