# Design Blackjack Hands, Splits, and a Multi-Deck Shoe Design the core object model for a blackjack game. A player may split two equal-valued cards, producing multiple active hands, and a newly created hand may be split again when allowed. The game uses a six-to-eight-deck shoe, and a cut card near the bottom signals that the shoe should be reshuffled at the correct round boundary. Explain relationships, state transitions, and dealing behavior. ### Constraints & Assumptions - A player can own more than one hand during a round. - A split replaces one playable hand with two child hands while preserving bet and outcome tracking. - The cut card does not interrupt a hand already in progress; it schedules a reshuffle after the round. - Exact casino limits such as maximum splits should be configurable rules rather than constants in the Hand class. ### Clarifying Questions to Ask - Are aces treated differently after a split? - May a split hand be split again, and what is the maximum hand count? - When exactly is the cut card checked relative to drawing the next card? ```hint Model hands as entities Keep each hand's cards, bet, and status independent while the player owns the collection. ``` ```hint Separate signal from action Crossing the cut card sets a reshuffle-needed flag; the table performs the reshuffle between rounds. ``` ### What a Strong Answer Covers - Composition between Player and a collection of Hand objects rather than copying Player state. - A split state transition that is safe for repeated splits and stable hand identifiers. - A Shoe abstraction covering deck construction, shuffle, deal, cut-card state, and round-boundary reset. - Tests for scoring, split mutation, card exhaustion, and delayed reshuffle. ### Follow-up Questions - How would you preserve an audit log that can replay every deal and split? - How would concurrent tables draw from independent shoes while sharing one rules configuration?