Requirements

Functional Requirements:

• Players place their mark (X or O) on an empty cell of the 3x3 grid. The system rejects placements on occupied cells.
• The system strictly alternates turns between the two players; X always moves first. A player cannot move out of turn.
• After each move, check all rows, columns, and both diagonals for three matching marks. If the board is full with no winner, declare a draw. Reject moves on occupied cells or out-of-turn moves.
• Players can start a new game at any time. The board clears, turn resets to X, and game status returns to active.

Non-Functional Requirements:

List the key non-functional requirements (eg thread safety, extensibility, maintainability, etc.)...

Core Objects & Relationships

Based on the requirements and use cases, identify the main objects of the system and analyze how they interact and relate to each other...

APIs & Class Members

For each class, define the attributes (data) it will hold and the methods (functions) that operate on the attributes. Ensure they align with the object's responsibilities and adhere to the principle of encapsulation. Write your code in the code editor below.

Deep Dive

Explain design tradeoffs you considered. Check and explain whether your design adheres to SOLID principles. Explain how your design can handle changes in scale and whether it would be easy to extend with new functionalities. Identify areas for future improvement...

I have used strategy pattern, making it flexible to new rules or strategy to play game

flexible no. of players

using Single Responsibility as board and player handle are just model classes and rule class only handling game rules while Game interface managing overall game

Open for extension closed for modification ensured by abstraction layer introduced for game rules, making it open to new rules in future

Liskov substitution followed, as the derived classes of IRules are implementing all its parent properties and good to replace parent

Interfacesegmentation is not required here because anyways there is single functionality to be supported by currently all strategies

Dependency inversion also applied as at run tIME instance of concrete class Rule is created using Irules abstract class

future improvements: logic to check draw can be optimized and validations to check valid move can be enhanced further