Case Study: A Chess Game

Case Study: A Chess Game — Tech Epitome

The brief

Two players play standard chess on one device. The program must reject illegal moves, detect check, checkmate and stalemate, support castling, en passant and promotion, and allow moves to be undone. A computer opponent, clocks and network play are out of scope for now.

Entities

Entity	Is the only thing that knows
Position (square)	A file and rank on the board — an immutable value
Piece	Its type and colour
Board	Which piece stands on which square
GameState	Side to move, castling rights, en passant target, move counters
Move	From, to, and what kind of move it is
Rules	Which moves are legal in a given state, and what the result is
Game	The sequence of moves played and how to undo them

Board and GameState are separate because castling rights are not visible from piece placement.

java

1public record Position(int file, int rank) {2    public Position {3        if (file < 0 || file > 7 || rank < 0 || rank > 7)4            throw new IllegalArgumentException("off board: " + file + "," + rank);5    }6 7    public Optional<Position> offset(int df, int dr) {8        int f = file + df, r = rank + dr;9        return (f < 0 || f > 7 || r < 0 || r > 7)10            ? Optional.empty()11            : Optional.of(new Position(f, r));12    }13}

An invalid square cannot be constructed, so nothing downstream checks.

Polymorphism or a table?

The textbook design is an abstract Piece with a subclass per piece type, each overriding a method that lists where it can move. It reads naturally and it works. It is worth asking, though, what actually differs between the subclasses.

java

1abstract class Piece {2    final Colour colour;3    Piece(Colour colour) { this.colour = colour; }4    abstract List<Position> candidateMoves(Position from, Board board);5}6 7final class Knight extends Piece {8    private static final int[][] JUMPS =9        {{1,2},{2,1},{2,-1},{1,-2},{-1,-2},{-2,-1},{-2,1},{-1,2}};10 11    Knight(Colour colour) { super(colour); }12 13    List<Position> candidateMoves(Position from, Board board) {14        List<Position> out = new ArrayList<>();15        for (int[] j : JUMPS)16            from.offset(j[0], j[1])17                .filter(to -> !board.hasPieceOf(to, colour))18                .ifPresent(out::add);19        return out;20    }21}22// ... Bishop, Rook and Queen repeat the same sliding loop with other directions

Subclass per piece: six classes, mostly the same loop.

java

1enum PieceType {2    KNIGHT(false, new int[][]{{1,2},{2,1},{2,-1},{1,-2},{-1,-2},{-2,-1},{-2,1},{-1,2}}),3    BISHOP(true,  new int[][]{{1,1},{1,-1},{-1,1},{-1,-1}}),4    ROOK(true,    new int[][]{{1,0},{-1,0},{0,1},{0,-1}}),5    QUEEN(true,   new int[][]{{1,1},{1,-1},{-1,1},{-1,-1},{1,0},{-1,0},{0,1},{0,-1}}),6    KING(false,   new int[][]{{1,1},{1,-1},{-1,1},{-1,-1},{1,0},{-1,0},{0,1},{0,-1}}),7    PAWN(false,   new int[][]{});   // pawns are special; a rule handles them8 9    final boolean slides;10    final int[][] directions;11    PieceType(boolean slides, int[][] directions) {12        this.slides = slides;13        this.directions = directions;14    }15}16 17// One generator serves every piece except the pawn.18List<Position> candidates(Piece piece, Position from, Board board) {19    List<Position> out = new ArrayList<>();20    for (int[] d : piece.type().directions) {21        Optional<Position> next = from.offset(d[0], d[1]);22        while (next.isPresent()) {23            Position to = next.get();24            if (board.hasPieceOf(to, piece.colour())) break;     // own piece blocks25            out.add(to);26            if (!piece.type().slides || board.isOccupied(to)) break;  // capture ends a slide27            next = to.offset(d[0], d[1]);28        }29    }30    return out;31}

Table-driven: the differences are data, so they are written as data.

Approaches

How to model what pieces can do

Subclass per piece
Time
Virtual call per piece
Space
Six classes
Pieces genuinely behave differently — fairy-chess variants with pieces that swap, teleport or have effects beyond movement.
Table of directions
Time
One loop for all
Space
One enum
Standard chess, where five of six pieces differ only in directions and whether they slide.
Table for geometry, rule objects for special moves
Taught here
Time
One loop plus a few rules
Space
Enum plus small rule classes
The usual best answer: geometry as data; pawn moves, castling, en passant and promotion as separate rules that can each be tested alone.

Validating a move

There is a piece on the from-square and it belongs to the side to move.
The destination is in that piece's pseudo-legal set: geometry, blocking and capture only.
Special-move rules are satisfied: castling rights and empty, unattacked transit squares; the en passant target; promotion on the last rank.
After applying the move, the mover's own king is not attacked. This step catches pins and moving into check.

java

1List<Move> legalMoves(GamePosition pos, Colour side) {2    List<Move> legal = new ArrayList<>();3    for (Move m : pseudoLegal(pos, side)) {4        Undo undo = pos.apply(m);                       // make5        if (!isAttacked(pos, pos.kingOf(side), side.opponent()))6            legal.add(m);7        pos.undo(undo);                                 // unmake8    }9    return legal;10}11 12GameStatus status(GamePosition pos, Colour side) {13    boolean inCheck = isAttacked(pos, pos.kingOf(side), side.opponent());14    if (!legalMoves(pos, side).isEmpty()) return inCheck ? GameStatus.CHECK : GameStatus.ONGOING;15    return inCheck ? GameStatus.CHECKMATE : GameStatus.STALEMATE;16}

Checkmate and stalemate are the same test with one bit different.

Moves as values, undo as a command

Undo needs more than from and to. Reversing a capture needs the captured piece; reversing a king move needs the castling rights that existed before it; reversing anything needs the previous en passant square. Record what a move destroyed at the moment it is applied, and undo becomes exact. This is the Command pattern with its undo half taken seriously.

java

1enum MoveKind { NORMAL, DOUBLE_PAWN_PUSH, CASTLE_KINGSIDE, CASTLE_QUEENSIDE, EN_PASSANT, PROMOTION }2 3record Move(Position from, Position to, MoveKind kind, Optional<PieceType> promotion) {}4 5// Everything apply() overwrote, so undo() can restore it exactly.6record Undo(Move move,7            Optional<Piece> captured,8            CastlingRights castlingBefore,9            Optional<Position> enPassantBefore,10            int halfmoveClockBefore) {}

Both records are immutable, so history can be shared and replayed safely.

Before and after

What undo needs to know

Move(from, to) only

e5 to d6

captured: ?

castling rights: ?

en passant was: ?

undo: guesswork

Move plus Undo record

e5 to d6, EN_PASSANT

captured: pawn on d5

Trade-offs and extensions

Draw rules — threefold repetition needs a hash of each position, which is a reason to keep GameState compact and comparable from the start.
Chess960 changes only the castling rule and the starting set-up; with castling as its own rule object, that is one replacement class.
Clocks are an observer of 'move played' events with their own timer; the rules never need to know about time.
A computer opponent needs millions of make and unmake operations per second, which pushes the board towards bitboards — a case where performance, not elegance, would change the model.

Search Tech Epitome

Search Tech Epitome

Case Study: A Chess Game

The brief

Entities

Polymorphism or a table?

How to model what pieces can do

Subclass per piece

Table of directions

Table for geometry, rule objects for special moves

Validating a move

Moves as values, undo as a command

What undo needs to know

Trade-offs and extensions

You’ve reached the end