Lab Coding Exercise: Refactoring Code into Multiple Classes

In this lab, you will refactor a working game of Hangman to remove code duplication. Refactoring is the process of changing the implementation of a piece of code without changing the functionality. The result of this lab will be a Hangman game that functions the same as the initial game, but has less duplication and is easier to read and update.

The lab has 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.

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. When Pair Programming, 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 Project Information → Members (in the upper left corner) 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..

Read the Original Code

Background

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. To simulate this in lab, there are two similar versions of the game that include 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.

Discussion

In this section, you will read over the two classes above and discuss it with your partner. Then, you add short summaries of your discussion to the Original Code section of DISCUSSION.md file.

Note: you only need to consider the code in the game package, not the util package.

Overview

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?

Adding new Functionality

To help identify candidate code within each game that could be turned into methods to represent a player's behavior, describe 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.

For this discussion, do not worry about the exact Java code needed to implement these players, just identifying what lines in either one of the game classes needs to be changed to implement two new players described above.

To guide your discussion, consider what parts of the code do the two game classes have in common and what parts are different (note, use can use Window → Editor Tabs → Split Right to view the two classes side by side):

• 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?
• The method handleGuess() 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 other parts of the code can be factored out into shorter methods?

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

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.

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

• HangmanGame
• Guesser
• SecretKeeper

The main objective of this refactoring is to ensure these classes have no duplicated code. You will also separate the game rules from the player logic so that they can be changed independently.

Update the Refactoring Plan section of the DISCUSSION.md file. Write down the methods you will create for each of the three classes, HangmanGame, Guesser, and SecretKeeper. 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.

You can do this using standard Java syntax followed by a comment. For instance,

public String sayHello(String name)
// creates a greeting in the format "Hello, {name}"

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.

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 20 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 adding the logic from the original AutoHangmanGame.

No changes should need to be made to the HangmanGame or Main classes. For now, just comment out the interactive implementation. We will see a better way to handle this next week.

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 adding the logic from the original AutoHangmanGame.

No changes should need to be made to the HangmanGame or Main classes. For now, just comment out the random implementation. We will see a better way to handle this next week.

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 - everyone's 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:

• 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.
• 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.