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

Lets start by clarifying the requirements:

1. Clarifying 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.

1.1 Functional Requirements

1.2 Non-Functional Requirements

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

2. Identifying Core Entities

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.

3. Designing Classes 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.

3.1 Class Definitions

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. 

Why not just use characters directly?

Because Symbol.X is self-documenting and type-safe. You can't accidentally pass 'Z' where a symbol is expected. The compiler catches invalid symbols at compile time, not runtime.

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.

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: if (cell.isEmpty()) is clearer than if (cell.getSymbol() == Symbol.EMPTY).

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.

The Board doesn't know about players or game rules. It just manages a grid of cells. This separation means we could reuse Board for other grid-based games.

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.

3.2 Class Relationships

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.

3.3 Key Design Patterns

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.

Why Strategy Pattern?

We could use a simple switch statement or a series of if-else blocks. However, 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. Observers implement a common interface.

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().

Why Singleton Pattern?

Singleton is often overused, but it's appropriate here because:

3.4 Full Class Diagram

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

Try It Yourself (Exercise)

Before looking at the complete implementation, try building the Tic-Tac-Toe system yourself. Below you'll find template stubs for all the classes we designed. Each stub includes method signatures and // TODO comments where you need to add the implementation logic.

Your task: Implement all the // TODO sections based on the design we discussed. Once complete, run the demo to verify your implementation produces the expected output.

4. Code Implementation

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.

5. Run and Test

6. Quiz