Loading LLD design...
Design an object-oriented chess game with a full piece hierarchy (King, Queen, Rook, Bishop, Knight, Pawn) where each piece type defines its own movement rules via polymorphism. The board is an 8×8 grid initialised with the standard starting position.
The game enforces turn-based play (white first), validates that moves are legal (piece can reach the target, move doesn't leave own king in check), handles captures, and detects check, checkmate, and stalemate. Special moves include castling (kingside and queenside), en passant, and pawn promotion. Moves are recorded in algebraic notation.
Board initialisation
Set up an 8×8 board with 32 pieces in the standard starting position
Piece movement rules
Each piece type (King, Queen, Rook, Bishop, Knight, Pawn) has unique movement rules
Move validation
Validate: correct turn, piece can reach destination, no self-check after move
Capture
Moving onto an opponent's piece captures it
Check detection
Detect when a king is under attack (in check)
Checkmate detection
Detect when a player has no legal moves and their king is in check
Stalemate detection
Detect when a player has no legal moves but is NOT in check (draw)
Special moves
Handle castling (kingside/queenside), en passant, and pawn promotion
Move history
Record moves in algebraic notation; support undo
Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.
Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.
Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.
What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.
What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.