Object-Oriented Design of a Battleship Game

Design the game of Battleship in code. Start from the basic classes and interfaces, then work through the game's operations, how the board's state is represented and updated, and how the game decides whether an attack hits a ship. The report lists the topics the discussion covered rather than a rule set, so the rules below are those of the standard game; confirm them with the interviewer. In the standard game, each of two players places a fleet of ships of fixed lengths on their own square grid: each ship lies horizontally or vertically, inside the grid, without overlapping another ship, and the opponent cannot see this grid. The players then take turns firing at one cell of the opponent's grid. Every shot is announced as a miss, a hit, or a hit that sinks a ship, and the first player to sink the whole opposing fleet wins. ### Clarifying Questions - What are the board size and the fleet: fixed, or configurable? - Two human players, or one player against the computer? - May ships touch each other? Is diagonal placement allowed? - What does a shot at a cell that was already targeted do: raise an error, waste the turn, or allow a retry? - Does a hit earn another shot, or do turns always alternate? - Is the game played locally, or over a network where the clients cannot be trusted? ### Part 1 — Classes and interfaces Propose the main classes and their responsibilities, and the public interface that a client, such as a user interface or a computer player, would call. ```hint Two views of one board A player needs to see their own ships, but only the results of their own shots on the opponent's board. Decide which object owns the truth and what each player is allowed to see. ``` #### What This Part Should Cover - Responsibilities of the game, board, ship and coordinate abstractions - A small public interface for placing ships and firing, with explicit result types - Hiding the opponent's ship positions from a player ### Part 2 — Game operations and board state Define the operations (placing ships, starting play, firing, ending the game) and how each board's state is stored and updated. Enforce the rules: valid placement, turn order, and repeated shots. ```hint Phases The same call can be legal in one phase of the game and illegal in another. List the phases and which operations each allows. ``` #### What This Part Should Cover - A game state machine (placement, play, finished) and turn enforcement - Placement validation: bounds, overlap and fleet composition - The board representation, and how a shot updates it, including a repeated shot ### Part 3 — Deciding whether an attack hits Given a shot at a cell, decide whether it hits a ship, which ship, whether that ship is now sunk, and whether the game is over. State the cost of each of these checks. ```hint From cell to ship A hit has to update a specific ship, not only a cell. Think about what lookup takes you from a coordinate to the ship occupying it, and how a ship knows that it has sunk. ``` #### What This Part Should Cover - A constant-time lookup from a cell to the ship on it - Sunk and game-over detection without rescanning the board - Correct results for misses, hits, sinking hits and repeated shots ### What a Strong Answer Covers - Clarifies the rules before modeling them - A clean split of responsibilities, with information hidden between the players - Explicit game phases and validated operations with clear errors - An efficient board representation with constant-time shot resolution and sink tracking - Room to extend (board size, fleet, a computer player) and code that is easy to test ### Follow-up Questions - How would you implement a computer opponent that searches efficiently after its first hit? - How would you make the game playable over a network so that neither client can learn where the other's ships are? - How would you support a variant with special shots that strike several cells at once? - How would you test the game logic?