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.

Practice

1. What is the main purpose of having a base Piece class in a board game design?

easy

A. To manage network communication between players

B. To define common properties like position and type for all pieces

C. To handle user input events

D. To store the entire board layout

Solution

1. Step 1: Understand the role of a base class

   A base class provides shared properties and methods for all derived classes, avoiding repetition.

2. Step 2: Apply to board game pieces

   All pieces share common traits like position and type, so the base Piece class holds these.

3. Final Answer:

   To define common properties like position and type for all pieces -> Option B

4. Quick Check:

   Base class = common properties [OK]

Hint: Base class holds shared traits for all pieces [OK]

Common Mistakes:

• Confusing board layout storage with piece properties
• Thinking base class handles user input
• Assuming base class manages network tasks

2. Which of the following is the correct way to declare a subclass King that extends a base Piece class in a typical object-oriented design?

easy

A. class King extends Piece { constructor(position) { super(position); } }

B. function King() { this.position = position; } extends Piece

C. class King inherits Piece { constructor() { } }

D. King = Piece + position

Solution

1. Step 1: Identify correct subclass syntax

   In modern OOP, a subclass uses extends keyword and calls super() in constructor.

2. Step 2: Check each option

   class King extends Piece { constructor(position) { super(position); } } uses correct syntax: class King extends Piece { constructor(position) { super(position); } }.

3. Final Answer:

   class King extends Piece { constructor(position) { super(position); } } -> Option A

4. Quick Check:

   Subclass syntax = extends + super() [OK]

Hint: Subclass uses extends and calls super() in constructor [OK]

Common Mistakes:

• Using incorrect keywords like inherits
• Placing extends after function declaration
• Trying to add properties with '+' operator

3. Given this code snippet for a board and pieces, what will be the output of console.log(board.pieces[0].type);?

class Piece {
  constructor(type, position) {
    this.type = type;
    this.position = position;
  }
}
class Board {
  constructor() {
    this.pieces = [];
  }
  addPiece(piece) {
    this.pieces.push(piece);
  }
}
const board = new Board();
board.addPiece(new Piece('Knight', 'B1'));

medium

A. undefined

B. "B1"

C. Error: pieces is not defined

D. "Knight"

Solution

1. Step 1: Understand object creation and storage

   A new Piece with type 'Knight' and position 'B1' is created and added to board.pieces.

2. Step 2: Access the first piece's type

   board.pieces[0] refers to the first piece, so board.pieces[0].type is 'Knight'.

3. Final Answer:

   "Knight" -> Option D

4. Quick Check:

   First piece type = 'Knight' [OK]

Hint: First piece type is stored in pieces[0].type [OK]

Common Mistakes:

• Confusing position with type
• Assuming pieces array is empty
• Expecting an error due to missing pieces

4. Identify the error in this piece hierarchy code snippet:

class Piece {
  constructor(type, position) {
    this.type = type;
    this.position = position;
  }
}
class Queen extends Piece {
  constructor(position) {
    this.type = 'Queen';
    this.position = position;
  }
}

medium

A. Position should not be passed to constructor

B. Queen class should not have a constructor

C. Missing call to super() in Queen constructor

D. Type should be passed as parameter to Queen constructor

Solution

1. Step 1: Review subclass constructor rules

   In subclasses, the constructor must call super() before using this.

2. Step 2: Check Queen constructor

   Queen constructor assigns this.type and this.position without calling super(), causing an error.

3. Final Answer:

   Missing call to super() in Queen constructor -> Option C

4. Quick Check:

   Subclass constructor must call super() first [OK]

Hint: Always call super() before using this in subclass constructor [OK]

Common Mistakes:

• Forgetting super() call in subclass constructor
• Trying to assign this before super()
• Assuming constructor is optional in subclass

5. You want to design a scalable board game system where each piece type has unique movement rules. Which design approach best supports adding new piece types without changing existing code?

hard

A. Use a base Piece class and create subclasses for each piece type implementing their own move logic

B. Store all piece types and moves in a single large switch-case statement

C. Keep piece types as strings and handle moves in a separate global function with if-else

D. Use a flat list of pieces with no hierarchy and hardcode moves in the board class

Solution

1. Step 1: Understand scalability and extensibility

   Good design allows adding new piece types without modifying existing code, following open-closed principle.

2. Step 2: Evaluate design options

   Subclassing Piece lets each piece implement its own move logic, enabling easy extension.

3. Final Answer:

   Use a base Piece class and create subclasses for each piece type implementing their own move logic -> Option A

4. Quick Check:

   Subclassing = scalable and extensible design [OK]

Hint: Subclass each piece type for unique moves [OK]

Common Mistakes:

• Using large switch-case blocks that are hard to maintain
• Handling moves globally with if-else reduces flexibility
• Hardcoding moves in board class limits scalability