Piece movement rules (polymorphism) in LLD - System Design Exercise

Design: Chess Piece Movement System

Design focuses on piece movement logic and rules using polymorphism. It excludes UI, game state management, and network communication.

Functional Requirements

FR1: Support different chess pieces with unique movement rules (Pawn, Rook, Knight, Bishop, Queen, King).

FR2: Allow querying valid moves for any piece on a given board state.

FR3: Enforce movement constraints like board boundaries and piece blocking.

FR4: Support extension to add new piece types with custom movement rules without changing existing code.

Non-Functional Requirements

NFR1: System should respond to move queries within 50ms.

NFR2: Support up to 32 pieces on the board simultaneously.

NFR3: Design should be maintainable and extensible for future piece types.

NFR4: Memory usage should be minimal to run on low-resource devices.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Piece base class/interface with move validation method

Derived classes for each piece type implementing specific rules

Board representation to check piece positions and boundaries

Move validator that uses polymorphism to get valid moves

Factory or registry to create piece instances

Design Patterns

Polymorphism for piece movement rules

Factory pattern for piece creation

Strategy pattern for encapsulating movement algorithms

Template method for common move validation steps

Open/Closed principle for extensibility

Reference Architecture

  +---------------------+
  |       Board         |
  | - grid: 8x8 array   |
  +----------+----------+
             |
             v
  +---------------------+       +---------------------+
  |      Piece (base)   |<------+  PieceFactory        |
  | - position          |       | - createPiece(type)  |
  | + getValidMoves()   |       +---------------------+
  +----------+----------+
             |
  +----------+----------+----------+----------+----------+----------+
  |          |          |          |          |          |          |
  v          v          v          v          v          v          v
Pawn      Rook       Knight     Bishop      Queen      King      CustomPiece
(move rules implemented in each subclass using polymorphism)

Components

Piece (abstract base class)

Object-oriented class/interface

Defines common interface for all pieces including getValidMoves method.

Pawn, Rook, Knight, Bishop, Queen, King (derived classes)

Object-oriented subclasses

Implement specific movement rules for each piece type using polymorphism.

Board

2D array or matrix

Represents the chessboard and tracks piece positions to validate moves.

PieceFactory

Factory design pattern

Creates piece instances based on type to support extensibility.

Request Flow

1. Client requests valid moves for a piece at a position.

2. Board provides the piece instance at that position.

3. Client calls getValidMoves() on the piece instance.

4. Piece subclass computes moves based on its rules and board state.

5. Piece returns list of valid moves considering boundaries and blocking.

6. Client receives valid moves to use for game logic or UI.

Database Schema

Not applicable - system is in-memory object-oriented design without persistent storage.

Scaling Discussion

Bottlenecks

Complexity of move calculation if many pieces or custom rules added.

Performance impact if board state checks are inefficient.

Difficulty extending system if polymorphism is not properly used.

Solutions

Use efficient data structures for board and caching intermediate results.

Apply design patterns like Strategy to isolate complex movement logic.

Ensure clear interface and open/closed principle to add new pieces without modifying existing code.

Optimize move validation by pruning impossible moves early.

Interview Tips

Time: 10 minutes to clarify requirements and constraints, 20 minutes to design class hierarchy and data flow, 10 minutes to discuss scaling and extensions, 5 minutes for questions.

Explain polymorphism benefits for piece movement rules.

Describe how each piece class encapsulates its own logic.

Show how board state is used to validate moves.

Discuss extensibility for new piece types without code changes.

Mention performance considerations and caching strategies.