# Design Tennis Scoring with Pluggable Rules ### Prompt Design a small scoring component for one tennis game between two players. It must record which player won each point, report a human-readable score, and identify when the game has ended and who won. Under standard scoring, the first points are displayed as Love, 15, 30, and 40. Once both players have at least three points, equal scores are Deuce, a one-point lead is Advantage, and a two-point lead wins the game. Extend the design so another scoring policy, such as no-ad scoring at Deuce, can be selected without putting rule-specific conditionals throughout the game object. **Candidate hint:** Keep the facts that happened separate from the policy that interprets those facts. ### Constraints & Assumptions - Only one game is in scope; set and match scoring are out of scope. - Calls after a game is complete must have defined behavior. - Player identity must not depend on display names being unique. - The score policy may control display and terminal-state rules. ### Clarifying Questions to Ask - Should the component preserve a point-by-point audit trail or only current counts? - Should invalid calls raise errors or return explicit result objects? - Can the scoring policy change after a game begins? ### What a Strong Answer Covers - A compact domain model with unambiguous invariants - Correct standard tennis score and win transitions - A Strategy-style boundary that contains rule variation - Useful API behavior, validation, and testability - Trade-offs between storing events and storing derived counters ### Follow-up Questions 1. How would you add undo for a mistakenly recorded point? 2. What changes if scores must be reconstructed from an event log? 3. How would you serialize a game without serializing executable strategy objects? 4. Which cases belong in a table-driven test suite?