Object-Oriented Design of a Two-Player Chess Game: Board, Pieces, Moves, Game End

In an object-oriented design phone screen, the question was: design chess. Design the classes for a two-player chess game that can be played to completion. Cover the board, the pieces and how each moves, turns, validation of a requested move, and detection of the end of the game. Then code the core classes and walk through how one move is validated and applied. ```hint Geometry versus legality Separate what a piece can do geometrically from what the game allows given the rest of the board. ``` ```hint The rule every piece shares Decide where the rule "a move may not leave your own king in check" lives, since it applies to every piece type. ``` ### Clarifying Questions - Is this two humans at one board, or do computer players, remote players or a UI need to fit in? - Must special moves be supported: castling, en passant, pawn promotion? - Which endings are required: checkmate and stalemate only, or also resignation, draw offers, threefold repetition and the fifty-move rule? - Are clocks, move history, undo or saving games in scope? ### What a Strong Answer Covers - Clear responsibilities for the board, pieces, moves, players and game, with low coupling between them - Piece movement expressed without a giant conditional, and shared logic for sliding pieces - A legal-move check that rejects moves leaving one's own king in check - Game-state handling: turns, check, checkmate and stalemate - Special moves and the state they require (whether pieces have moved, the last move) - Extensibility trade-offs: inheritance versus composition, and copying the board versus making and unmaking moves ### Follow-up Questions - How would you add undo, and what must each move record to make it possible? - How would you detect a draw by threefold repetition? - How would your design change to support a chess variant with a new piece type? - Where would a computer opponent plug in, and what would it need from your classes?