Why chess tests polymorphism and strategy in LLD - Design It to Understand It

Design: Chess Game System

Design focuses on the core chess game logic and piece movement rules. UI, network play, and AI opponents are out of scope.

Functional Requirements

FR1: Support all standard chess pieces with their unique moves

FR2: Allow players to make moves according to chess rules

FR3: Enforce turn-based play between two players

FR4: Detect check, checkmate, and stalemate conditions

FR5: Support undo and redo moves

FR6: Allow saving and loading game states

Non-Functional Requirements

NFR1: System must be extensible to add new piece types easily

NFR2: Move validation latency must be under 100ms

NFR3: System should handle up to 1000 concurrent games

NFR4: Maintain game state consistency at all times

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Piece classes with polymorphic move methods

Game engine to manage turns and rules

Board representation and state management

Move validator component

Undo/redo stack for moves

Design Patterns

Polymorphism for piece behavior

Strategy pattern for move validation

Command pattern for moves and undo/redo

Observer pattern for game state changes

Reference Architecture

  +-------------------+
  |    Game Engine    |
  +---------+---------+
            |
  +---------v---------+
  |    Board State    |
  +---------+---------+
            |
  +---------v---------+       +----------------+
  |   Piece (Base)    |<------+  Move Validator |
  +---------+---------+       +----------------+
            |
  +---------+---------+
  |  Pawn | Rook | ... |
  +-------------------+

Components

Piece Base Class

Object-Oriented Classes

Defines common interface for all chess pieces with polymorphic move generation

Concrete Piece Classes

Inheritance

Implement specific move rules for Pawn, Rook, Knight, Bishop, Queen, King

Game Engine

Class/Module

Manages game flow, turn order, and special rules like check/checkmate

Board State

Data Structure (2D array or map)

Tracks current positions of pieces and game status

Move Validator

Strategy Pattern

Validates moves according to piece rules and game state

Undo/Redo Manager

Command Pattern

Allows reversing and reapplying moves

Request Flow

1. Player requests a move for a piece

2. Game Engine asks the Piece object to generate possible moves (polymorphism)

3. Move Validator checks if requested move is valid given current Board State

4. If valid, Game Engine updates Board State and switches turn

5. Game Engine checks for check, checkmate, or stalemate

6. Move is recorded in Undo/Redo Manager for possible reversal

Database Schema

Entities: - Game: id, player_white_id, player_black_id, current_turn, status - Move: id, game_id, piece_type, from_position, to_position, timestamp - Piece: type, position, color Relationships: - Game has many Moves - Moves reference Pieces by type and positions - Game tracks current Board State as serialized data or separate Piece records

Scaling Discussion

Bottlenecks

Move validation latency when many concurrent games run

Memory usage for storing many game states and move histories

Complexity in adding new piece types without breaking existing logic

Solutions

Cache frequently used move patterns and precompute legal moves where possible

Use efficient data structures and serialize game states compactly

Use polymorphism and strategy pattern to isolate piece-specific logic for easy extension

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for design and architecture, 10 minutes for scaling and trade-offs, 10 minutes for Q&A

Explain how polymorphism helps represent different pieces with unique moves

Describe strategy pattern use for move validation

Discuss how game engine manages rules and state

Highlight extensibility for new pieces

Mention performance considerations for move validation and state management