Lab Coding Exercise: Refactoring Code into Multiple Classes

In this lab, you will refactor two working games of Hangman to remove code duplication and clarify their differences. Refactoring is the process of changing the implementation of a piece of code without changing the functionality.

In pairs of your choosing, complete the following steps:

1. Setup Pair Programming Environment
2. Read the Original Code
3. Plan your Refactoring
4. Refactor
5. Debrief
6. Submit Your Work

Please complete each step before moving onto the next.

The result of this lab will be a Hangman game that functions the same as the initial game, and generalize the result into a single game with multiple classes as options for change.

Setup Pair Programming Environment

Labs in this course expect you to work either in pairs or with your project team.

Professionally, this practice is called Pair Programming. In class meetings, you will:

• Collaborate with a partner, sharing one computer for coding
• Switch coding roles every 10-15 minutes (In industry, this switch is less frequent because programmers pair for longer than our lab).
• The non-coding partner focuses on advising, searching for solutions, and reviewing documentation, but never multitasking

Follow these steps to setup your Pair Programming environment:

1. Choose a Partner’s Computer to Work On: Both partners will code using the same computer, called the Driver Station. (If you are uncomfortable with sharing a computer, see Simulating Pair Programming Across Machines for alternative setups. However, please note these will make the lab more complicated and make it take longer).
2. Fork Project on Gitlab: One partner should Fork the original project lab_hangman to their repository to allow pushing your pair's changes.
   • On the resulting project web page, go to Manage → Members (in the left side panel) to add your partner so both people in the group can access the same repository
   • Search for your partner's name and give them a Maintainer role in the project and choose Add to Project
3. Clone Repository in Terminal: On the Driver Station, git clone to copy the forked repository to the local machine.
4. Open Project in IntelliJ: On the Driver Station, open the cloned folder in IntelliJ to start a new project.
5. Update DISCUSSION.md: In IntelliJ, add group members’ names and NetIDs at the top of DISCUSSION.md.
6. Add, Commit, and Push DISCUSSION.md: This will ensure your whole lab setup is functioning end-to-end.

Note: When pair programming, it is a good idea for the non-coding partner to have a copy of the code in front of them for reference. This will also help in the next section.

Before Moving On: Add your names to the DISCUSSION.md file, then add, commit the file, and push to your forked lab_hangman repository.

Review the Original Code

In the game of Hangman, one player tries to guess a secret word that another player has chosen by guessing a letter at a time. There are two similar versions of the game that simulate four different kinds of players (based on assignments given in CompSci 101). A player is either a guesser or secret keeper.

• HangmanInteractiveGame.java: An interactive guesser versus a secret keeper that chooses a random secret word.
• HangmanAutoGame.java: An auto guesser that chooses letters based on frequency versus a sneaky secret keeper that changes the secret word after each guess to maximize the remaining possible words.

Refactoring is the practice of updating a program to improve its design and maintainability without changing its current functionality. For example, creating a single method from two similar code blocks to reduce duplicate code.

Discussion

Review the two classes linked above first with your partner to identify what lines of code in their respective play() method represent behavior specific to the various guesser or secret keeper players. Consider opening them in separate windows and viewing them side by side.

Do not look at the versions in the repository yet.

While it is not essential to understand the algorithm used by the sneaky secret keeper, consider using an LLM to help explain the code to you rather than spending significant time inspecting it. After reviewing the code yourself, prompt an LLM for suggestions to get its take on your thoughts or suggest new ideas.

To guide your discussion, consider the following questions:

• What pieces of code help versus obscure your understanding?
• What comments could be removed and replaced with better variable names or by calling shorter methods?
• What Code Smells can you find?

The method play() is composed of several steps:

• Which ones are always the same for every game and which ones depend on what kind of player is playing?
• What parts of the code can be factored out into shorter methods?

Another way to help identify candidate code within each game that could be turned into methods, consider how would you make the following new game using the current design:

• A clever guesser that automatically chooses letters based minimizing the remaining words versus an interactive secret word keeper that lets the user choose the secret word interactively.

Do not worry about the exact Java code needed to implement these players, just identifying what lines in either one of the game classes need to be changed to implement the new players described above.

In the DISCUSSION.md file, write down the methods you will create. For each method, specify

• the method name
• the method arguments (and their types)
• the method return type
• a one sentence summary of why it is needed

The goal of this step is not to get all the implementation details exactly correct, but rather to develop an understanding of how the classes need to interact with each other to remove duplication.

Before Moving On: Write short summaries of your discussion in the DISCUSSION.md file, then add, commit the file, and push to your forked lab_hangman repository.

Plan Your Refactoring

In this section, you will plan several refactoring steps to change two classes with heavily duplicated code into the following three classes with no duplicated code:

• HangmanGame
• Guesser
• SecretKeeper

You will also separate the game rules from the player logic so that they can be changed independently.

Now consider the code that you cloned. It has already been refactored to create several short, private methods such that the two play() methods are identical and all of the differences have been factored out into some of the methods (some methods are still duplicated and represent the same behvaior). Thus your task now is to:

• create those classes and their constructors
• determine which methods belong in which of the three classes above
• choose their respective instance variables
• replace the existing code with calls to methods on instances of those classes

To help you in this process, consider the following:

• Which class (HangmanGame, Guesser, or SecretKeeper) should be responsible for these instance variables (and why): mySecretWord, myNumGuessesLeft, myDisplayWord, and myLettersLeftToGuess?

Your pair may create any new methods or classes you want to help improve the program. However, because the functionality of the program should not change in this refactoring, you should focus primarily on moving existing code rather than creating any new code.

Before Moving On: Write short summaries of your discussion in the DISCUSSION.md file, then add, commit the file, and push to your forked lab_hangman repository.

Refactor

Using pair programming in 15 minute increments (or after each change described below), perform the refactoring your planned above.

First, rename InteractiveHangmanGame to HangmanGame. For the rest of your refactoring, you will gradually extract functionality out of HangmanGame into Guesser and SecretKeeper classes. Below, an ordering of steps is provided, but not the changes themselves. You will need to implement the methods you defined your Refactoring Plan. It’s fine if you need to alter the methods from what you originally planned to make things work.

Note: Please leave at least 10 minutes at the end of lab to Debrief and Submit your Work. It is okay if you are not finished with your refactoring by then. Just find a stopping place (ideally with working code), commit your changes, and move on to Debrief.

Interactive Guesser

• Create a Guesser class that implements the interactive guessing using the methods from your plan
• Update the Main class to create the Guesser and pass it to the HangmanGame
• Update the HangmanGame class to call methods on the Guesser in place of its own methods

Make sure you can play an interactive game using your new Guesser.

Add and commit your changes to the source code before moving on.

Random SecretKeeper

• Create an SecretKeeper class that implements choosing a random secret word using the methods from your plan
• Update the Main class to create the SecretKeeper and pass it to the HangmanGame
• Update the HangmanGame class to call methods on the SecretKeeper in place of its own methods

Make sure you can play an interactive game using both the Guesser and your new SecretKeeper.

Add and commit your changes to the source code before moving on.

Auto Guesser

• Update your Guesser class to implement choosing letters automatically by using the logic from the original AutoHangmanGame.
  For now, comment out the interactive guesser code and replace it with the auto guesser code. We will see a better way to handle this next week.

No changes should need to be made to the HangmanGame or Main classes.

Make sure you can run an auto game using both the Guesser and your new SecretKeeper.

Add and commit your changes to the source code before moving on.

Sneaky SecretKeeper

• Update your SecretKeeper class to implement changing the secret word after each guess by using the logic from the original AutoHangmanGame.
  For now, comment out the interactive guesser code and replace it with the auto guesser code. We will see a better way to handle this next week.

No changes should need to be made to the HangmanGame or Main classes.

Make sure you can run an auto game using both the Guesser and the sneaky version of the SecretKeeper.

Before Moving On: Add and commit your changes to the source code and push them to your forked lab_hangman repository.

Debrief

In this section, review your changes (or planned changes if you did not get to implement everything). Then, you add short summaries of your discussion to the Debrief section of DISCUSSION.md file.

Extending Functionality

Discuss with your partner, as concretely as you can, how to implement these changes using this new version of the code:

• Two new players described above (clever guesser and interactive secret keeper).
  This should not require any changes to the HangmanGame class.
• How would you create games featuring match ups between different types of players, rather than commenting and uncommenting code?
  This should require only adding if statements and parameters to the constructor sent from the main() method, not copying any existing classes.

Reflection

Taking the totality of the lab in mind, discuss the following with your partner:

• In what ways is the refactored code simpler and more intentional?
• In what ways is the refactored code more complex?
• What trade-offs did you make when refactoring the original code?
• Which code do you prefer and why?

Submitting Your Work

At the end of lab, use Gitlab's Merge Request from your forked repository's main branch back to the original organization repository's main branch to submit your group's answers to the discussion questions and your refactored code.

Make the Title of your Merge Request is of the form "lab_hangman - NetIDs".

You only need to create one Merge Request, no matter how many commits you make, and you do not worry about potential conflicts since your request will not be approved (it is just an easy way for us to see what changes you made).

Appendix

Simulating Pair Programming Across Machines

If you are using two machines for Pair Programming, then both lab partners need to clone the environment (as instructed above).

You have two options for synchronizing across machines:

• IntelliJ’s CodeWithMe: you can also use IntelliJ’s CodeWithMe, which will synchronize changes across machines. This is collaborative editing software and allows both users to make changes simultaneously. When pair programming, you should instead allow one partner to drive, write the code, while another provides feedback rather than both simultaneously coding different parts of the program.
• Gitlab pushes and pull: you will need to commit and push changes to Gitlab after each partner codes. Then, the other partner will need to pull the changes.
  We will practice these in depth in a future lab. For this lab, choose the simplest workflow you are comfortable using.