Jotto: Refactoring GUI Code for Extensibility

This project is intended to get you to practice some of the programming and design techniques discussed in class recently, specifically writing GUIs and developing inheritance hierarchies. The problem is to simulate a game of jotto as given in this previous assignment from CompSci 100. A complete solution to the problem is given in Java as a starting point.

Understanding the Design

Start by reading the given code and making sure you understand it. The following questions should guide your analysis of the design of the current code:

• Why is the code separated into a JottoModel and a JottoViewer? What advantages, if any, does this separation provide?
• If you were to draw a picture of the information exchanged between these classes, what would it look like?
• What would be required to add additional views to this program? Is any part of the program closed to this change?
• How does the model differentiate between a human and a computer guessing?
• How does the GUI differentiate between a human and a computer guessing?

Refactoring

Refactor the current code to use an inheritance hierarchy of player types such that it minimizes the amount of new code required to add another computer player. Specifically, the current code uses a variety of conditional statements to determine if the computer or the user is playing. You should create an abstract class, Player, that is implemented by at least two concrete classes, HumanPlayer and ComputerPlayer, each created by the GUI that closes the model code to adding additional players.

Refactor the current code to use a resource file for all of the text strings shown to the user, either as labels on buttons, prompts, or messages given as feedback.

Refactor the current code so the number of guesses a player can make is correctly reflected in the number of text fields shown in the GUI.

Testing

You do not need to write unit tests for this program, however, there are at least two bugs in the code provided that you will need to find and fix.

Additionally, you should attempt to bullet-proof the code from bad input from the user. Several cases are already handled, but not all cases. For each case where the user can provide bad input, you should give back specific and constructive feedback to help the user understand and fix the problem.

Improving

Provide the player with two additional options in the GUI:

• the ability to ask for a hint; this should simply reveal a letter in the secret word
• a space to note which letters must be in or out of the solution; minimally, just a text field the user can type into; a better solution would be a grid of letters that could be clicked on to grey out or highlight

The current code includes only one computer player that guesses a word randomly that correctly conforms to its history of guesses. You should add at least one additional computer player that chooses its word to guess each time more intelligently than simply randomly.

To facilitate playing your computer solutions against each other, allow a two player option that allows two GUIs to be displayed at once, each with a different player in control.

For extra credit, come up with separate GUIs for computer and human players. These GUIs should share as much code as possible and have a similar look, but clearly differentiate the role the user plays in giving input to the model.