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.

Practice

1. What is the main benefit of using polymorphism for piece movement rules in a game design?

easy

A. It allows each piece to have its own move logic without type checks.

B. It forces all pieces to share the same move logic.

C. It requires manual checking of piece types before moving.

D. It prevents pieces from moving on the board.

Solution

1. Step 1: Understand polymorphism concept

   Polymorphism allows different objects to be treated through a common interface while having their own behavior.

2. Step 2: Apply to piece movement

   Each piece class implements its own move() method, so no need to check piece type before moving.

3. Final Answer:

   It allows each piece to have its own move logic without type checks. -> Option A

4. Quick Check:

   Polymorphism = own move logic without type checks [OK]

Hint: Polymorphism means no type checks for moves [OK]

Common Mistakes:

• Thinking all pieces share the same move logic
• Believing manual type checks are needed
• Confusing polymorphism with inheritance only

2. Which of the following is the correct way to declare a base class method for piece movement in a polymorphic design?

easy

A. move(self): pass

B. def move(self): pass

C. def move(): pass

D. def move(self, board): return

Solution

1. Step 1: Recall method declaration syntax in Python

   Instance methods must have self as the first parameter.

2. Step 2: Identify correct method signature

   def move(self): pass correctly declares a method with self and no implementation.

3. Final Answer:

   def move(self): pass -> Option B

4. Quick Check:

   Method with self parameter = def move(self): pass [OK]

Hint: Instance methods always start with self parameter [OK]

Common Mistakes:

• Omitting self parameter in method
• Using incorrect syntax without def keyword
• Adding unnecessary parameters without context

3. Given the following code, what will be the output?

class Piece:
    def move(self):
        return "Base move"

class Knight(Piece):
    def move(self):
        return "L-shaped move"

pieces = [Piece(), Knight()]
for p in pieces:
    print(p.move())

medium

A. Base move\nL-shaped move

B. L-shaped move\nL-shaped move

C. Error: move() not implemented

D. Base move\nBase move

Solution

1. Step 1: Understand method overriding

   Subclass Knight overrides move() to return "L-shaped move".

2. Step 2: Trace the loop output

   First object is Piece, prints "Base move"; second is Knight, prints "L-shaped move".

3. Final Answer:

   Base move\nL-shaped move -> Option A

4. Quick Check:

   Base class and overridden subclass moves printed [OK]

Hint: Subclass method overrides base method output [OK]

Common Mistakes:

• Assuming base method always runs
• Expecting same output for all pieces
• Confusing method overriding with overloading

4. Identify the error in the following polymorphic piece movement code:

class Piece:
    def move(self):
        pass

class Bishop(Piece):
    def move():
        print("Diagonal move")

b = Bishop()
b.move()

medium

A. Cannot instantiate Bishop directly

B. Piece.move() should return a value

C. Bishop.move() missing self parameter

D. print statement syntax error

Solution

1. Step 1: Check method signatures

   Bishop.move() lacks self parameter, so it is not a proper instance method.

2. Step 2: Understand call context

   Calling b.move() passes self automatically, causing a TypeError due to missing parameter.

3. Final Answer:

   Bishop.move() missing self parameter -> Option C

4. Quick Check:

   Instance methods must have self parameter [OK]

Hint: Instance methods always need self parameter [OK]

Common Mistakes:

• Ignoring missing self in subclass method
• Thinking base class method must return value
• Assuming print syntax is wrong

5. You are designing a chess game using polymorphism for piece movement. How should you structure your classes to allow easy addition of new piece types without changing existing code?

hard

A. Write a single move() function with if-else for each piece type.

B. Implement move logic only in the base class and override rarely.

C. Use global variables to track piece types and moves.

D. Create a base Piece class with an abstract move() method; each piece subclass implements move().

Solution

1. Step 1: Apply polymorphism design principle

   Use a base class with an abstract or empty move() method to define interface.

2. Step 2: Implement subclasses for each piece

   Each piece subclass provides its own move() logic, enabling extension without modifying base code.

3. Final Answer:

   Create a base Piece class with an abstract move() method; each piece subclass implements move(). -> Option D

4. Quick Check:

   Base class + subclass move() = scalable design [OK]

Hint: Base class with abstract move() enables easy extension [OK]

Common Mistakes:

• Using if-else instead of polymorphism
• Relying on global variables for logic
• Putting all move logic in base class only