Skip to content

Latest commit

 

History

History
91 lines (79 loc) · 5.18 KB

F17_lab05.md

File metadata and controls

91 lines (79 loc) · 5.18 KB
Raw

Plan to Refactor Entire Code Base

The code health at its current state isn't looking great and we believe a MVC design pattern can take the convoluted code and reorganize it so that every file has a logical place in the following directories: Model, View, and Controller. The goal of the refactor is to break unhealthy relationships between files so that each file can be placed in a directory that has clearly defined roles. In doing so, we would be following the single responsibility principle and future classes working on this project will be able to clearly see the function and role of every module.

Reviewing the current code

The current source files are placed into three different directories: AI, GUI, and Logic. Upon brief scanning of the code we can immediately see files that have unhealthy relationships. For example, there are multiple modules in the GUI directory such as Board.java the handles logic. The board itself should not have knowledge on how to handle logistics of the connect four game. The MVC model aims to refactor this code so that the code can be more readable and a convenient reoccuring theme of the MVC design pattern shown below can be established.

Image of MVC Process Model

The AI Directory

The current AI directory contains the following files:

  • AIDebuggingOutput.java
  • SinglePlayerAdvanced.java
  • SinglePlayerEasy.java
  • SinglePlayerNormal.java
  • TestSinglePlayerAdvanced.java
  • TestSinglePlayerEasy.java
  • TestSinglePlayerNormal.java

Although there is no issue with having an AI directory for the AI modules and AI test modules, to keep up with our theme of following the MVC model, we will place these files inside the Controller directory. The files themselves contain purely the logics of every AI level. Therefore there is no need to change anything at the file level (with the exception of changing the package import lines once the project is refactored).

The GUI Directory

The current GUI directory contains the following files:

  • AbstractMenu.java
  • BoardColorSelectMenu.java
  • BoardDisplay.java
  • Circle.java
  • InGameMenu.java
  • MainMenu.java
  • Player1ColorSelectMenu.java
  • Player2ColorSelectMenu.java
  • RulesPage.java
  • SettingsMenu.java
  • SinglePlayerMenu.java
  • StartScreen.java

The GUI directory is a close representation of the View directory. The files in this directory would be moved into the View directory. However, at its current state, the BoardDisplay.java file is coupling responsibilities of the Model and the View. The model should be handling the state of the game and the view simply displaying the state. We get into how this issue can be resolved when we look at the files in the logic directory.

The Logic Directory

The Logic directory contains the following files:

  • Board.java
  • Game.java
  • IntPair.java
  • TestBoard.java
  • Tuple.java

The Logic directory is the main culprit of unhealthy coupling. The Board.java file contains logics of AI. The board itself should have no knowledge of how the game of connect four works or any knowledge on the display of the board. We should remove any "playing of the game" within the Board.java file and create a Player module within the controller directory that handles all things concerning the actual game of connect four. The Board.java file should be placed within the model direcory and dynamically update the BoardDisplay.java file in view. This decoupling creates a more logical flow that the design pattern pushes for. Player.java will manipulate (play the game) by passing information onto the Board.java file which will then update the BoardDisplay.java dynamically. The next class should strip any functions that represent playing of connect four and place it in a Player.java file. The end result of a complete refactor would look like the following:

model/

  • Game.java
  • Board.java
  • LocationState.java
  • Move.java
  • IntPair.java
  • TestBoard.java
  • Tuple.java

view/

  • AbstractMenu.java
  • BoardColorSelectMenu.java
  • BoardDisplay.java
  • Circle.java
  • InGameMenu.java
  • MainMenu.java
  • Player1ColorSelectMenu.java
  • Player2ColorSelectMenu.java
  • RulesPage.java
  • SettingsMenu.java
  • SinglePlayerMenu.java
  • StartScreen.java

controller/

  • Player.java
  • AIAgent.java(Interface)
  • SinglePlayerAdvanced.java
  • SinglePlayerNormal.java
  • SinglePlayerEasy.java
  • TestSinglePlayerAdvanced.java
  • TestSinglePlayerNormal.java
  • TestSinglePlayerEasy.java

It is important to thouroughly go through each of these files and ensure that each file is handling one responsibility of the MVC model. The only coupling that should exist between the controller and model files is if you must detect mouse clicks within the GUI. Although the complete refactoring of the project maintains all features (and adds none) and does not change user experience, it will make the code far more readable and any further issues or addition of features can be easily done without having to worry about if changing a single module will collide with the logic of the game or display of the game. The refactoring of the project into an MVC model will create a futureproof model that will prevent the need to "hack" in features. Features will simply require adjusting one or two modules.