Design Chess Game

1. Requirements & Assumptions

Functional Requirements

• The game is played on an $8 \times 8$ grid board.
• Supports two players (White and Black) taking alternate turns.
• Features standard chess pieces: King, Queen, Rook, Bishop, Knight, and Pawn.
• Each piece has specific movement rules (e.g., Rooks move horizontally/vertically).
• The system must validate moves (e.g., checking if a path is blocked or if a move is out of bounds).
• Tracks game states: Active, Checkmate, Stalemate, Resigned.

Non-Functional Requirements

• Modularity: Piece movement rules must be encapsulated so that adding custom pieces (e.g., in chess variants) is straightforward.
• Deterministic Rule Checks: Board state evaluations (like check/checkmate) must be precise.

Assumptions

• Advanced rules like castling, en passant, and pawn promotion are omitted in the initial version.
• The game is played locally on a single machine interface.

2. Entities, Responsibilities & Relationships

• ChessGame (Context): Coordinates players, turn transitions, and the board state.
• Board: Manages the $8 \times 8$ grid of cells and queries piece locations.
• Cell: Represents a square on the board identified by coordinates $(x, y)$, holding a reference to a piece.
• Piece (Abstract): Base class containing color, and declaring the abstract canMove(board, start, end) method.
• Pawn, Rook, Knight, etc.: Concrete pieces implementing specific move validation logic.
• Move: Records a history entry (player, start cell, end cell, piece killed).

3. Diagrams

UML Class Diagram

Sequence Diagram: Making a Move

4. Design Decisions

• Piece Polymorphism: Instead of managing movement rules with nested switch statements inside Board, we encapsulate move validation inside each piece class using polymorphism.
• Coordinate Cell Model: Cells are modeled as independent object entities containing $(x, y)$ coordinates. This simplifies bounds checking and board status queries.

5. Step-by-Step Implementation

1. Create the abstract Piece class with a color flag (isWhite).
2. Implement concrete pieces: Rook and Knight (handling straight and L-shaped moves respectively).
3. Implement the Cell class to model coordinates and hold pieces.
4. Implement Board to initialize the $8 \times 8$ grid.
5. Create the ChessGame context to manage turns, players, and move execution.

6. Complete Code

7. Test Cases & Verification

• Test Case 1: Valid Knight Move: Move a Knight from $(0,1)$ to $(2,2)$. Verify that the move is allowed and the turn swaps to Black.
• Test Case 2: Out of Turn Move: Attempt to move a Black piece on White's turn. Verify that the move is rejected.
• Test Case 3: Invalid Move Pattern: Attempt to move a Knight in a straight line. Verify that the move is rejected.

8. Scalability & SOLID Improvements

• SOLID - Single Responsibility Principle: The Board only manages grid coordinates and piece placements. It has no knowledge of turn rules or game state transitions, which are managed by the ChessGame class.
• Command Pattern for Move History: To support features like undoing moves or listing game history, we can encapsulate moves as MoveCommand objects. This allows us to undo moves easily by calling command.undo().

9. Production Considerations

• State Persistence: To allow players to resume games later, save move histories in databases (e.g., in a JSON column in PostgreSQL) using standard algebraic chess notation (e.g., 1. Nf3 d5).
• Distributed Multiplayer (Websockets): To support online matches, run the game state on a central server and use Websockets to sync moves and update client UIs in real-time.

10. Summary

This completes the LLD Case Studies module. We have applied SOLID principles and design patterns (like State, Strategy, and Facade) to design real-world systems, preparing you for low-level system design interviews!