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

Practice

1. In the context of chess and system design, what does polymorphism primarily demonstrate?

easy

A. Chess pieces cannot change their behavior during the game

B. Chess pieces all move in the same way regardless of type

C. Chess strategy is about random moves without planning

D. Different chess pieces use the same method name but have unique move behaviors

Solution

1. Step 1: Understand polymorphism in chess pieces

   Polymorphism means objects share the same interface but behave differently. Chess pieces all have a move method but move uniquely.

2. Step 2: Relate polymorphism to chess piece behavior

   Each piece type (pawn, knight, bishop) implements move differently, showing polymorphism.

3. Final Answer:

   Different chess pieces use the same method name but have unique move behaviors -> Option D

4. Quick Check:

   Polymorphism = Same method, different behavior [OK]

Hint: Polymorphism means same method, different actions [OK]

Common Mistakes:

• Thinking all pieces move the same way
• Confusing polymorphism with inheritance only
• Ignoring that method names are shared

2. Which of the following code snippets correctly shows polymorphism for chess pieces in a low-level design?

easy

A. class Piece { move() { /* generic move */ } } class Pawn extends Piece { move() { /* pawn move */ } }

B. class Pawn { move() { /* pawn move */ } } class Knight { jump() { /* knight jump */ } }

C. function move(piece) { if(piece.type == 'pawn') { /* move */ } else { /* no move */ } }

D. class Piece { move() { console.log('move'); } } let piece = new Piece(); piece.move();

Solution

1. Step 1: Identify polymorphism in code

   Polymorphism requires a base class with a method overridden by subclasses. class Piece { move() { /* generic move */ } } class Pawn extends Piece { move() { /* pawn move */ } } shows a base Piece class with move(), overridden by Pawn.

2. Step 2: Check other options for polymorphism

   class Pawn { move() { /* pawn move */ } } class Knight { jump() { /* knight jump */ } } lacks shared method names; function move(piece) { if(piece.type == 'pawn') { /* move */ } else { /* no move */ } } uses conditional logic, not polymorphism; class Piece { move() { console.log('move'); } } let piece = new Piece(); piece.move(); has no subclassing.

3. Final Answer:

   class Piece { move() { /* generic move */ } } class Pawn extends Piece { move() { /* pawn move */ } } -> Option A

4. Quick Check:

   Base class + overridden method = polymorphism [OK]

Hint: Look for base class with overridden methods [OK]

Common Mistakes:

• Confusing conditional logic with polymorphism
• Missing method overriding in subclasses
• Ignoring inheritance structure

3. Given the following pseudo-code, what will be the output when calling move() on each piece in the list?

class Piece { move() { return 'generic move'; } } class Knight extends Piece { move() { return 'L-shape move'; } } class Bishop extends Piece { move() { return 'diagonal move'; } } pieces = [new Piece(), new Knight(), new Bishop()] for p in pieces: print(p.move())

medium

A. L-shape move\ndiagonal move\ngeneric move

B. generic move\nL-shape move\ndiagonal move

C. generic move\ngeneric move\ngeneric move

D. Error: move method not found

Solution

1. Step 1: Understand method overriding in subclasses

   Each subclass overrides move() to return its specific move string.

2. Step 2: Trace the loop calling move()

   For Piece instance, move() returns 'generic move'. For Knight, 'L-shape move'. For Bishop, 'diagonal move'.

3. Final Answer:

   generic move\nL-shape move\ndiagonal move -> Option B

4. Quick Check:

   Overridden methods print their own strings [OK]

Hint: Each subclass method overrides base method output [OK]

Common Mistakes:

• Assuming base method output for all pieces
• Mixing order of outputs
• Expecting runtime errors incorrectly

4. Identify the error in this chess piece design code snippet:

class Piece { move() { throw 'Not implemented'; } } class Queen extends Piece { } let q = new Queen(); q.move();

medium

A. Queen class should not inherit from Piece

B. Piece class should not have a move() method

C. Queen class does not override move(), causing runtime error

D. No error, code runs fine

Solution

1. Step 1: Analyze base class move() method

   Piece.move() throws an error if called directly, indicating it must be overridden.

2. Step 2: Check Queen class implementation

   Queen does not override move(), so calling q.move() calls base method and throws error.

3. Final Answer:

   Queen class does not override move(), causing runtime error -> Option C

4. Quick Check:

   Abstract method not overridden = runtime error [OK]

Hint: Abstract methods must be overridden to avoid errors [OK]

Common Mistakes:

• Assuming base method runs without error
• Thinking inheritance is wrong here
• Ignoring the throw statement in base method

5. How does combining polymorphism and strategy in chess help design a flexible and smart system?

hard

A. Polymorphism allows different piece behaviors; strategy plans moves ahead for better decisions

B. Polymorphism forces all pieces to behave identically; strategy ignores future moves

C. Strategy replaces polymorphism by hardcoding moves; polymorphism is unnecessary

D. Polymorphism and strategy are unrelated concepts in system design

Solution

1. Step 1: Understand polymorphism's role in flexibility

   Polymorphism lets different pieces share an interface but act differently, enabling flexible design.

2. Step 2: Understand strategy's role in smart planning

   Strategy involves planning moves ahead to make smart decisions, improving system intelligence.

3. Step 3: Combine both concepts

   Together, polymorphism provides flexible behaviors, and strategy guides smart choices, creating a robust system.

4. Final Answer:

   Polymorphism allows different piece behaviors; strategy plans moves ahead for better decisions -> Option A

5. Quick Check:

   Polymorphism + strategy = flexible, smart system [OK]

Hint: Polymorphism = flexibility; strategy = planning [OK]

Common Mistakes:

• Thinking polymorphism means identical behavior
• Ignoring the importance of planning in strategy
• Separating polymorphism and strategy as unrelated