Refactor/hw-2

[ruslanaprus]

The SonarLint plugin was used to identify issues related to clean code standards, and the code was subsequently refactored.

Refactoring Description

1. Renamed Variables

• In the original code, variables such as box, i and rand were ambiguously named.
• Refactored Code: Variables were renamed to more descriptive names like gameBoard, currentPlayer, and move.

2. Extracted Methods

• In the original code, logic for checking the game winner, handling user input, and printing the game board was embedded within the main method.
• Refactored Code: The logic was extracted into separate methods (makeMove, makeUserMove, makeComputerMove, checkWinner, printBoard, etc.) for better organisation.

3. Extracted Classes

• In the original code, the App class was responsible for all tasks, including user interaction, game logic, and board management.

• Refactored Code: Responsibilities were distributed among multiple classes:

  • TicTacToeGame manages the game flow.
  • Board handles board management.
  • Player manages player-related logic.
  • Result deals with game outcomes.
  • Message handles user interactions and console output.

  Specifics:

  1. The App class serves as the entry point, creating an instance of TicTacToeGame and starting the game by calling the play method.
  2. The TicTacToeGame class manages the game loop, controls the flow, and handles player and board interactions, including checking win conditions and displaying results.
  3. The Board class encapsulates the game board's state and includes methods for resetting the board, printing it, checking for a winner or draw, and updating cell values.
  4. The Player enum represents the two players, USER and COMPUTER, and contains their respective marks ('X' and 'O'). It also includes a next() method for switching between players.
  5. The Result enum defines possible game outcomes: USER_WON, COMPUTER_WON, and DRAW.
  6. The Message utility class centralises all user interaction logic, handling console output and formatted text.

4. Moved Methods

• Refactored Code: Methods related to board management (e.g., initializeNumberedBoard, resetBoard, printBoard, checkRows, checkColumns, checkDiagonals, checkDraw, etc.) were moved to the Board class, where they logically belong. This class now encapsulates all board-related operations.
• The TicTacToeGame class now focuses on the game flow, including taking turns, making moves, and determining the game outcome. It uses the Board class to interact with the board.

5. Removed Duplication

• The original code had duplicated logic for checking if a player had won for both players.
• Refactored Code: This logic was generalised and encapsulated within methods like checkWinner, checkRows, checkColumns, and checkDiagonals in the Board class.

6. Replaced Conditionals with Polymorphism

• The original code relied on conditionals to check the winner, switch players, and handle moves.
• Refactored Code: Polymorphism was introduced through the Player and Result enums to represent players and game outcomes, reducing the need for conditionals. This change simplifies the code structure, making it more extensible and easier to modify.

7. Consolidated Methods

• Refactored Code: Similar operations were consolidated into methods like makeMove, which delegates tasks to makeUserMove or makeComputerMove based on the player. This consolidation reduces code duplication and centralises similar operations, leading to a more maintainable codebase.

8. Scanner Resource Management

• Refactored Code: The Scanner instance used for user input was properly closed by utilizing a try-with-resources block in the App class. This ensures that the Scanner resource is automatically closed after its use, preventing potential resource leaks.

9. Exception Handling for Invalid Input

• Refactored Code: The getUserMove method in the TicTacToeGame class was refactored to handle exceptions related to invalid user input. Specifically, a try-catch block was added to catch NumberFormatException when the user enters non-numeric input. The user is prompted to enter a valid move until a correct input is provided.