Board and piece hierarchy in LLD - System Design Exercise

Design: Board and Piece Hierarchy

Focus on the class hierarchy and interactions for board and pieces. Do not cover UI or network communication.

Functional Requirements

FR1: Design a system to represent a game board and its pieces.

FR2: Support multiple types of pieces with different movement rules.

FR3: Allow querying piece positions and valid moves.

FR4: Enable adding, moving, and removing pieces on the board.

FR5: Support different board sizes and shapes.

Non-Functional Requirements

NFR1: The system should be extensible to add new piece types easily.

NFR2: Operations like move validation should be efficient for real-time use.

NFR3: The design should separate board logic from piece logic.

NFR4: The system should be usable for turn-based games with up to 100 pieces.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Board class to represent the game board and its cells.

Abstract Piece class with common attributes and methods.

Concrete Piece subclasses for each piece type with specific move logic.

Position or Coordinate class to represent locations on the board.

Move validator or strategy pattern for piece movements.

Design Patterns

Inheritance for piece hierarchy.

Strategy pattern for move validation.

Composite pattern if pieces can contain other pieces.

Factory pattern to create pieces dynamically.

Observer pattern if board state changes need to notify other components.

Reference Architecture

Board and Piece Hierarchy Diagram

+-----------------+       uses       +----------------+
|     Board       |<-----------------|    Position    |
|-----------------|                  +----------------+
| - size          |                          ^
| - grid          |                          |
| + addPiece()    |                  +----------------+
| + movePiece()   |                  |    Piece       |
| + removePiece() |                  |----------------|
+-----------------+                  | - position     |
        |                            | - color        |
        | contains                   | + validMoves() |
        v                            +----------------+
+-----------------+                         ^
|   Cell          |                         |
|-----------------|                  +----------------+
| - position      |                  |  Pawn, Rook,    |
| - piece         |                  |  Knight, etc.   |
+-----------------+                  +----------------+

Components

Board

Class

Represents the game board grid, manages pieces placement and movement.

Position

Class

Represents coordinates or location on the board.

Piece (abstract)

Abstract Class

Defines common attributes and methods for all pieces, like position and move validation.

Concrete Piece subclasses

Classes

Implement specific movement rules for each piece type (e.g., Pawn, Rook).

Cell

Class

Represents a single board cell that may hold a piece.

Request Flow

1. 1. Initialize Board with size and create grid of Cells.

2. 2. Create Piece instances with initial Positions.

3. 3. Add Pieces to Board by placing them in corresponding Cells.

4. 4. When a move is requested, Board asks the Piece if the move is valid.

5. 5. Piece uses its movement rules to validate the move.

6. 6. If valid, Board updates the Piece position and Cell occupancy.

7. 7. Board can query Pieces and their positions anytime.

Database Schema

Not applicable for this low-level design focused on class hierarchy and in-memory objects.

Scaling Discussion

Bottlenecks

Move validation logic can become complex with many piece types.

Board size increase may impact performance of move queries.

Adding new piece types may require code changes if not designed for extensibility.

Solutions

Use strategy pattern to encapsulate move logic per piece type for easier extension.

Optimize board representation with efficient data structures (e.g., hash maps for positions).

Cache valid moves for pieces when possible to reduce repeated calculations.

Design piece classes with interfaces to allow adding new types without modifying existing code.

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing class hierarchy and interactions, 10 minutes discussing scaling and extensibility, 5 minutes summarizing.

Explain separation of concerns between Board and Piece classes.

Describe how inheritance helps model different piece behaviors.

Discuss move validation strategy and how it supports extensibility.

Mention how the design supports different board sizes and piece counts.

Highlight how the design can be extended for new game rules or pieces.