Why Piece movement rules (polymorphism) in LLD? - Purpose & Use Cases

The Big Idea

What if you could add a new chess piece without rewriting your entire game logic?

The Scenario

Imagine building a chess game by writing separate code for each piece's movement rules everywhere you need them.

For example, when checking if a move is valid, you write different checks for pawns, knights, bishops, and so on, scattered all over your code.

The Problem

This manual approach is slow and confusing.

Every time you add a new piece or change a rule, you must hunt down all places where movement is checked and update them.

This leads to bugs, duplicated code, and frustration.

The Solution

Using polymorphism, each piece knows how it moves by itself.

You create a common interface for pieces, and each piece class implements its own movement rules.

This keeps code clean, easy to update, and scalable.

Before vs After

✗ Before

if piece == 'pawn': check_pawn_move()
elif piece == 'knight': check_knight_move()
// repeated in many places

✓ After

class Piece:
    def can_move(self, start, end): pass

class Pawn(Piece):
    def can_move(self, start, end):
        # pawn move logic
        pass

class Knight(Piece):
    def can_move(self, start, end):
        # knight move logic
        pass

What It Enables

You can add new pieces or change rules easily without breaking existing code.

Real Life Example

In a chess app, polymorphism lets you add a new custom piece with unique moves by just creating a new class, without touching the rest of the game logic.

Key Takeaways

Manual movement checks cause duplicated, hard-to-maintain code.

Polymorphism lets each piece handle its own moves cleanly.

This makes the system scalable and easy to extend.