Cell, Player, Position (game state)

View: Board.display(), console output (presentation)

Controller: Game class (orchestrates flow, handles input)

Benefits:

Easy to swap console UI for GUI
Game logic testable without UI
Clear separation of concerns

5. Encapsulation (Cell State Management)

Intent: Hide piece state behind cell abstraction.

Implementation:

Cell class owns piece state
Provides flip() method that handles logic internally
Client code doesn't manipulate piece state directly

Benefits:

Board grid operations are atomic
Flipping logic centralized in Cell
Easy to add cell-level features (e.g., highlighting)

cell.flip(); // Internally handles piece.opposite()

6. Factory Method Pattern (Board Initialization)

Intent: Encapsulate object creation logic.

Current Implementation:

private void initializeBoard() {
    // Creates 64 Cell objects with proper positions
    // Sets up initial 4-piece configuration
}

Benefits:

Board construction logic centralized
Easy to modify starting configuration
Could support alternate game modes (different initial positions)

8. Key Design Decisions

Decision 1: Immutable Position Class

Rationale: Coordinates shouldn't change after creation. The move() method returns a new Position rather than mutating the original.

Benefits:

No defensive copying needed
Safe to use as HashMap keys
Thread-safe
Clearer semantics (positions don't "move", you get new positions)

Trade-off: Slightly more memory allocation, but modern JVMs handle this efficiently.

Decision 2: Separate MoveValidator Class

Rationale: Move validation is complex (8 directions, multiple flips) and deserves its own class.

Benefits:

Single Responsibility Principle
Easy to unit test validation logic
Game class stays focused on orchestration
Could swap validators for different rule variants

Alternative Considered: Putting validation in Board class would bloat it with complex logic.

Decision 3: Direction Enum with Deltas

Rationale: Each direction has associated row/column deltas. Storing them in the enum eliminates repetitive switch statements.

Benefits:

DRY: deltas defined once
Easy to iterate all directions: for (Direction dir : Direction.values())
Type-safe direction references

Code Elimination:

// Without enum approach (repetitive):
if (direction == "NORTH") { nextRow = row - 1; nextCol = col; }
else if (direction == "SOUTH") { nextRow = row + 1; nextCol = col; }
// ... 6 more cases

// With enum:
Position next = current.move(direction); // Clean!

Decision 4: Cell-Based Board Representation

Rationale: Each square is a Cell object containing position and piece state, rather than just a 2D array of enums.

Benefits:

Cells can have additional properties (e.g., highlighted, last move)
Encapsulates piece state and flip logic
Easier to add cell-specific behavior later

Trade-off: Slightly more memory than raw Piece[][] array, but worth it for extensibi

Related Tags