Jump to a problem, path or page
Jump to a problem, path or page
Updates as you edit. Run the review to record it; passing every check completes the problem.
Not yet passed: Game controller responsibility
Add Game controller and define its responsibility.
Not yet passed: Game responsibility
Add Game and define its responsibility.
Not yet passed: Board responsibility
Add Board and define its responsibility.
Not yet passed: Fleet validator responsibility
Add Fleet validator and define its responsibility.
Not yet passed: Shot history responsibility
Add Shot history and define its responsibility.
Not yet passed: View policy responsibility
Add View policy and define its responsibility.
Not yet passed: Game controller → Game
A directed path must connect Game controller to Game. Arrows represent requests, dependencies, or event flow.
Not yet passed: Game → Board
A directed path must connect Game to Board. Arrows represent requests, dependencies, or event flow.
Not yet passed: Game → Fleet validator
A directed path must connect Game to Fleet validator. Arrows represent requests, dependencies, or event flow.
Not yet passed: Game → Shot history
A directed path must connect Game to Shot history. Arrows represent requests, dependencies, or event flow.
Not yet passed: Game → View policy
A directed path must connect Game to View policy. Arrows represent requests, dependencies, or event flow.
Not yet passed: What should an opponent view reveal?
Not yet passed: What does a repeated shot do?
Not yet passed: When may play begin?
Not yet passed: Interfaces and invariants
Write at least 80 characters describing concrete operations, inputs, outputs, state and errors. This check measures completeness, not semantic correctness.
Not yet passed: Trade-offs and failure cases
Write at least 80 characters about alternatives, failure handling and edge cases. Review the reasoning yourself using the reference discussion.
Rule-based educational feedback. Notes are checked by length only; topology checks confirm directed reachability. These checks do not validate semantics, latency, reliability or every valid design.
Use an explicit placement/play/finished state machine, validated fleet geometry and unique shot records. A scoped view layer exposes public results without returning the opponent’s hidden board. Configure board dimensions and the required fleet lengths. Validate each ship as in-bounds, straight, contiguous and nonoverlapping; touching is permitted under this exercise’s rules. Lock fleet placement once both complete fleets are ready and transition to PLAYING with a defined first player. Internal ship/cell identities are immutable after this point. A shot validates phase, actor, bounds and uniqueness before mutation. Record miss/hit, mark a ship sunk only when all its distinct cells have been hit, and win when every opponent ship is sunk. Advance to the other player after every valid nonterminal shot under this variant. Invalid shots change nothing. ViewPolicy reveals own fleet and opponent shot knowledge only; terminal state rejects further shots.
There is no single correct diagram. Explain where yours differs and which requirement justifies it.