In this chapter, we will explore the low-level design of a tic tac toe game in detail.

Lets start by clarifying the requirements:

Before starting any design, it's important to ask thoughtful questions to uncover hidden assumptions, clarify ambiguities, and define the system's scope.

Here is an example of how a discussion between the candidate and the interviewer might unfold:

After gathering the details, we can summarize the key system requirements.

After the requirements are clear, the next step is to identify the core entities that we will form the foundation of our design.

How do you go from a list of requirements to actual entities/classes?

The key is to look for nouns in the requirements that have distinct attributes or behaviors. Not every noun becomes a class, but this approach gives you a starting point.

Let's walk through our requirements and identify what needs to exist in our system.

1. The game is played on a 3x3 grid.

The grid is central to everything. We need something to represent it. This gives us our first entity: Board.

But what is a grid made of? Individual squares. Each square can be empty or contain a symbol. This suggests a second entity: Cell. The Board will contain 9 Cells arranged in a 3x3 structure.

2. Two players take alternate turns, identified by markers ‘X’ and ‘O’.

We need to represent players. Each player has a name and an assigned symbol. This gives us the Player entity.

What about the symbols themselves?

We could use strings ("X", "O") or characters, but that's error-prone. What stops someone from creating a player with symbol "Z"?

Using an enum Symbol with values X, O, and EMPTY gives us type safety. The compiler will catch invalid symbols at compile time rather than runtime.

3. The game processes moves and determines game outcomes.

Something needs to coordinate the gameplay: accept moves, validate them, check for wins, switch turns. This orchestrator is our Game entity.

The game also needs to track its current state. Is it still in progress? Did someone win? Is it a draw?

We could use a boolean isGameOver and a winner field, but that gets messy. What if we need to distinguish between "X won" and "O won"?

An enum GameStatus with values IN_PROGRESS, WINNER_X, WINNER_O, and DRAW captures all possibilities cleanly.

4. The system should maintain a scoreboard across multiple games.

A single Game object handles one game. But our requirements say we need to track scores across multiple games. This suggests two more entities:

The TicTacToeSystem acts as a facade. External code doesn't need to know about Game, Board, or Scoreboard directly. It just calls system.createGame() and system.makeMove().

Entity Overview

Here's how these entities relate to each other:

We've identified three types of entities:

Enums define fixed sets of values. They provide type safety and make code self-documenting.

Data Classes primarily hold data with minimal behavior. Player and Cell are simple containers.

Core Classes contain the main logic. Board manages the grid, Game orchestrates gameplay, Scoreboard tracks history, and TicTacToeSystem ties everything together.

With our entities identified, let's define their attributes, behaviors, and relationships.

Now that we know what entities we need, let's flesh out their details. For each class, we'll define what data it holds (attributes) and what it can do (methods). Then we'll look at how these classes connect to each other.

We'll work bottom-up: simple types first, then data containers, then the classes with real logic. This order makes sense because complex classes depend on simpler ones.

Enums

Enums define fixed sets of values that provide type safety and make code self-documenting. Using enums prevents invalid states at compile time rather than runtime.

Symbol

Represents the values a cell can contain.

Each enum value maps to a display character for printing the board.

GameStatus

Defines the possible states of the game. Tracks where we are in the game lifecycle.

Four distinct states cover all possible game outcomes. A game starts as IN_PROGRESS and transitions to exactly one terminal state when it ends.

Notice that all terminal states are one-way. There's no transition from DRAW back to IN_PROGRESS, and no transition from WINNER_X to WINNER_O. Once a game ends, it stays ended.

Data Classes

Data classes are simple containers that hold data with minimal behavior. They represent the "nouns" in our system that have attributes but little logic.

Player

Holds player information.

The Player class is immutable. Once created, a player's name and symbol don't change. This prevents bugs where someone accidentally reassigns a player's symbol mid-game.

Cell

Holds the current value of a board position.

Unlike Player, Cell is mutable. It starts as EMPTY and gets set to X or O when a player makes a move.

The isEmpty() helper method makes calling code more readable:

Interfaces

Interfaces define contracts for interchangeable behavior.

WinningStrategy

After each move, the Game needs to check whether someone won. We could write three separate checks (row, column, diagonal) inline, but that's rigid. If the interviewer says "now add a four-corners win condition," you'd have to modify Game.

WinningStrategy defines the contract for win detection algorithms.

The Game iterates through all strategies without knowing which specific checks exist. Adding a new win condition is just a matter of creating a new class that implements this interface and adding it to the list.

GameObserver

When a game ends, other components might need to react. The Scoreboard records the result, but a logger might write to a file, or an analytics service might track game duration. We don't want Game to know about all of these.

GameObserver defines the contract for listening to game end events.

The Game notifies all observers when it ends. Observers decide what to do with the information. The Scoreboard extracts the winner and records the result. A future logger could extract the move count and game duration. Neither requires any changes to Game.

Core Classes

Core classes contain the actual game logic. They coordinate between data classes and implement the rules of the game.

Board

Encapsulates the 3x3 grid and handles all board-related operations including its state and the rules for checking win/draw conditions.

Game

The orchestrator that brings all components together and manages gameplay.

Game ties everything together. It owns the Board, knows the Players, tracks whose turn it is, and uses WinningStrategies to detect wins. When the game ends, it notifies observers (like the Scoreboard).

Scoreboard

Tracks wins across multiple games.

The Scoreboard implements GameObserver so it can automatically update when games end.

TicTacToeSystem

This is the public-facing facade.

External code only interacts with TicTacToeSystem. It doesn't need to know about Board, Cell, or WinningStrategy.

How do these classes connect? There are three types of relationships we use.

Composition (Strong Ownership)

Composition means one object owns another. When the owner is destroyed, the owned object is destroyed too.

Association (Weak Reference)

Association means one object uses another, but doesn't own it. Both objects have independent lifecycles.

Implementation (Interface Contract)

Implementation means a class fulfills an interface contract.

You might notice some structural patterns emerging in our design. Let's make them explicit and justify why each pattern is appropriate here.

Strategy Pattern (Win Detection)

The Problem: A player can win in three distinct ways: completing a row, a column, or a diagonal. If we hardcode all win conditions in a single method, we end up with a long, complex function that's hard to test and modify. Adding a new win condition (like "four corners" in a variant) would require changing existing code.

The Solution: The Strategy pattern encapsulates each win-checking algorithm in its own class. The Game holds a list of WinningStrategy implementations and iterates through them to check for a winner.

The Strategy pattern gives us:

Observer Pattern (Scoreboard Updates)

The Problem: When a game ends, the Scoreboard needs to update. The naive approach is to have the Game directly call scoreboard.recordWin(). But this couples the Game to the Scoreboard. What if we want to add analytics tracking? Or a replay recorder? Each new listener would require modifying the Game class.

The Solution: The Observer pattern decouples the Game (subject) from its listeners (observers). The Game maintains a list of observers and notifies them when the game ends.

Why Observer Pattern? 

For a single Scoreboard, direct method calls would work fine. We use Observer because:

Singleton Pattern (TicTacToeSystem)

The Problem: We need a single, globally accessible entry point to the system that maintains a consistent scoreboard across multiple games.

The Solution: The Singleton pattern ensures only one instance of TicTacToeSystem exists. It provides a global access point via getInstance().

Singleton is often overused, but it's appropriate here because we genuinely need one scoreboard shared across all games.

Now that we've designed our classes and relationships, let's bring this to life with code.

Now let's translate our design into working code. We'll build bottom-up: foundational types first, then data classes, then the classes with real logic. This order matters because each layer depends on the ones below it.

Does Tic-Tac-Toe actually need thread safety?

For a simple console application where Alice and Bob take turns typing, no. But consider a web-based version: two players in different browsers making HTTP requests to the same game server. Each request is handled by a separate thread, and both threads access the same Game object. Without synchronization, things can go wrong.

Race Condition: Simultaneous Moves

Setup: Alice (X) and Bob (O) are playing through a web interface. It's Alice's turn (currentPlayerIndex = 0). Alice clicks (0, 0) and Bob clicks (1, 1) at nearly the same time. Two HTTP request threads hit Game.makeMove() concurrently.

Without synchronization:

Result: Both cells contain X. Bob's move was lost. The turn counter wrapped around, so Alice would go again. The board state is corrupted.

With synchronization: 

The synchronized keyword on makeMove() ensures Thread-A acquires the lock first. Thread-A completes the entire move atomically (place symbol, check win, switch player). Only then does Thread-B acquire the lock. Thread-B now reads the updated currentPlayerIndex = 1, confirms it's Bob's turn, and places O correctly.

One of the best ways to validate a design is to see how it handles change. If adding a feature requires modifying multiple classes, the design has problems. If you can add features by creating new classes without touching existing code, you've achieved the Open/Closed Principle.

Let's walk through five common extension requests and see how our design handles them.

Scenario: "Add a win condition where occupying all four corners wins the game."

This is where the Strategy pattern shines. We add a new strategy class without touching any existing code.

To enable it, add one line to initializeStrategies():

What stays unchanged: RowWinningStrategy, ColumnWinningStrategy, DiagonalWinningStrategy, Board, Cell, Game logic, Observer pattern.

Scenario: "Support 4x4 and 5x5 boards."

Our design already handles this. The Board takes a size parameter, and strategies use board.getSize() instead of hardcoding 3.

For larger boards, you might want a configurable win length (e.g., "5 in a row on a 10x10 board"). That would require updating the strategies:

What stays unchanged: Board, Cell, Observer pattern, Scoreboard.

Scenario: "Add a computer player that makes moves automatically."

We introduce a MoveStrategy interface for selecting moves. This is separate from WinningStrategy, which checks for wins.

A simple random strategy:

A smarter minimax strategy (simplified):

The Game class can check if the current player has a MoveStrategy and auto-play:

What stays unchanged: Board, Cell, WinningStrategy implementations, Observer pattern.

Scenario: "Track move history and allow undo."

The Command pattern is perfect here. Each move becomes a command that can be executed and reversed.

Update the Game class to use commands:

What stays unchanged: Board, Cell, WinningStrategy, existing Game methods.

Scenario: "Add analytics tracking and replay recording."

The Observer pattern already supports this. Just create new observer implementations.

Register multiple observers:

What stays unchanged: Game class, Scoreboard, Board, strategies. The Game doesn't know or care what observers are watching it.