Practice Exercise: Inheritance and Debugging

This exercise is intended for you to practice developing and debugging inheritance hierarchies. You are also encouraged to use IntelliJ's Debugger to find bugs in the code, as in the previous lab, as well as simply understanding how the unfamiliar code works.

Submitting your Work

There will not be an official submission for this exercise, instead show your progress to a UTA during lab when you think you are finished to get feedback.

Workflow

Here is a review of the steps you will use to work with GIT during lab (as distinct from assigned team projects):

1. On Gitlab, one person should fork the original project lab_pig into their own repository to allow pushing your group's changes
   • On the resulting project web page, go to Settings → Members 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
2. In Terminal, both students should use git clone to copy the one forked repository to their individual machines so they can work on their own separate copies
3. In IntelliJ, both students should Open the cloned folder to create a new project on their personal machine
4. As a group, discuss how to debug and update the current code
5. In IntelliJ, refactor the code to improve its design (i.e., edit the code) using Pair Programming
6. In Terminal, use GIT to
• git add changed files
• git commit -m to describe your changes
• git push changes back to Gitlab
• git pull changes from Gitlab back to the local machine (if you are not sharing a single computer)
• Repeat as many times as needed, letting each person try the changes/GIT steps in related chunks

Buggy Program

For each bug you find:

• Comment out the buggy code
• Write a comment telling the cause of the error
• Write the correct code that fixes the error

In pairs, complete the debug the following programs using your forked version of the project. After each, add, commit, and push your changes to the code before continuing on to the next.

Game of Pig

The game of Pig is a point-based dice game in which the first player to score at least 100 points is the winner. This implementation includes a spinner that randomly generates pig noises to supplement the die rolls.

On a player’s turn, they roll a 6-sided die and spin the spinner:

• If the spinner lands on “GRUNT” the player loses all their points for the game so far and their turn is over.
• If the die roll is 1, the player loses the points gained on the current turn only, and the turn is over.
• For any other roll/die combination, the die roll contributes to the points accumulated for this turn.

The player can then decide to play again, risking the turn points, or to "hold" — that is, keep the points for the turn and cede the turn.

There are several bugs in the given code (you do not need to fix them in the order listed here, the numbering is just for reference):

1. Game throws a NullPointerException in the winner() method
2. Sometimes the spinner gives an ArrayIndexOutOfBounds Exception
3. The die sometimes rolls a 0
4. The game does not end when a player gets at least 100 points
5. The ComputerPlayer’s name gets printed as null instead of "R2D2"
6. Spinning "GRUNT" does not make the player lose all their points
7. A 1 and "GRUNT" combination results in the player losing their turn, but not all their point

After each bug you fix, use add and commit to "record" your progress through the exercise. Then push the commits when you are done.

Pair Programming

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

Professionally, this practice is called Pair Programming: working closely with another programmer, sharing a "single computer" that we will simulate using a shared computer, shared repository or use IntelliJ's new Code With Me feature. To ensure both people do some coding, you will switch which person actually writes the code every 10-15 minutes (in industry this switch happens only 1-3 times per day). The person who is not actively coding can be advising, suggesting better names, looking up documentation, or searching the Internet for solutions to small problems you are likely to face, but not multi-tasking (i.e., doing their own work or socializing).