Object-Oriented Design of a Two-Player Chess Game and Its Move Rules

Design a program that lets two people play chess against each other. The interviewer is looking for the object model: the classes, what each is responsible for, how they relate, and how a single move flows from a player's input through validation to an updated game state. Expect to write the core pieces of code, not just draw boxes. ### Constraints and Clarifications - Use the standard chess rules for piece movement and captures. Assume two human players on one device or one program instance unless the interviewer extends the scope. - Whether the first version must enforce every special rule (castling, en passant, pawn promotion, draw rules) is something to confirm; the design should accommodate them either way. - No graphical interface is required; a method call such as making a move from one square to another is enough. - Use any mainstream object-oriented language; Python-style code is fine. ### Clarifying Questions - Must the first version enforce castling, en passant, promotion and draw conditions, or only basic movement, check and checkmate? - Is it local play only, or should the model later support playing over a network or against a computer? - Are undo, a move history in standard notation, or saving and loading games required? - Is a game clock or time control in scope? ### Part 1 — Core classes and responsibilities Identify the classes you need and what each one owns. Show how pieces, the board, positions, moves, players and the game relate, and justify where movement rules live. ```hint Possible versus legal A piece knows how it moves. Decide which object should judge whether a move that fits the piece's pattern is actually allowed in the current position. ``` #### What This Part Should Cover - A small set of classes with single, clear responsibilities - How piece-specific movement is expressed (inheritance, composition or data) and why - Immutable value types for squares and moves - Explicit game state: whose turn it is, history, and how the game ended ### Part 2 — Validating moves and detecting the end of the game Implement making a move: reject moves that break a piece's movement rules, moves out of turn, and moves that leave the mover's own king attacked. Detect check, checkmate and stalemate, and show where special moves fit. ```hint Try it and look A move can follow a piece's pattern perfectly and still be illegal because of what it exposes. Consider evaluating the position after the move. ``` #### What This Part Should Cover - Generating candidate moves and then filtering them for king safety - Special moves that depend on history (castling, en passant) and promotion - Distinguishing checkmate from stalemate - Making a move reversible, for legality checks and for undo ### Part 3 — Extending the design Explain how your design supports undo and replay, a computer opponent or network play, and variations in the rules, and how you would test that move generation is correct. ```hint What a computer player needs Think about what an automated opponent must ask of the model that a person typing moves never does. ``` #### What This Part Should Cover - Move history as reversible records, and serialization for saving or sending games - A player abstraction that lets humans, computers or remote clients supply moves - Separation of rules from presentation - A testing strategy that catches subtle move-generation bugs ### What a Strong Answer Covers - Clear class boundaries that keep rules out of the user interface and out of unrelated classes - Correct legality checking, including pins and moving into check - Working code for the central move flow, not only a class diagram - Reasoned trade-offs (inheritance versus data-driven movement, copying versus apply-and-revert) - Edge cases such as castling through an attacked square and the promotion choice ### Follow-up Questions - How would you detect a draw by threefold repetition efficiently? - How would you change the board representation if move generation had to be fast enough for a computer opponent searching millions of positions? - How would you support a variant with a randomized back rank, where castling works differently? - How would you make the game server-authoritative for online play so a modified client cannot cheat?