Why Board and piece hierarchy in LLD? - Purpose & Use Cases

The Big Idea

Discover how a simple hierarchy can turn chaotic game code into a clean, powerful design!

The Scenario

Imagine trying to build a chess game by writing separate code for each piece and board position without any shared structure or rules.

You would have to manually handle every piece's movement, capture, and interaction individually.

The Problem

This manual approach quickly becomes confusing and full of repeated code.

It's easy to make mistakes, like forgetting a rule or mixing up piece behaviors.

Adding new pieces or changing rules means rewriting lots of code, which is slow and error-prone.

The Solution

Using a board and piece hierarchy organizes the game elements into clear layers.

Pieces inherit common behaviors, and the board manages positions and moves uniformly.

This structure reduces repetition, makes rules easier to enforce, and simplifies adding new pieces or features.

Before vs After

✗ Before

if piece == 'pawn': move_pawn()
if piece == 'rook': move_rook()
if piece == 'bishop': move_bishop()

✓ After

class Piece:
    def move(self): pass

class Pawn(Piece):
    def move(self):
        # pawn move logic
        pass

class Rook(Piece):
    def move(self):
        # rook move logic
        pass

What It Enables

This hierarchy enables building complex board games that are easy to maintain, extend, and understand.

Real Life Example

Chess apps use board and piece hierarchies to handle all pieces with shared rules and unique moves, making the game logic clean and scalable.

Key Takeaways

Manual coding of each piece and move is repetitive and error-prone.

A hierarchy groups shared behaviors and simplifies management.

It makes adding new pieces or rules easier and safer.

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