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 superclass, Player, that has at least two concrete subclasses, HumanPlayer and ComputerPlayer, each created by the GUI that closes the model code to adding additional players. The choice of player should be independent of the choice of the game's difficulty level.

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 the view (the program's GUI), but you do need thoroughly test the model (the program's logic). There are two bugs in the provided code (one in the view and one in the model) 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 not already revealed 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

Each player should be able to play as many games as they want, with their score tracked (including the minimum number of guesses needed to find the word). This data should be saved between runs of the program so it keeps track of the history of playing the game. If the user chooses, this data should be cleared so the score history is reset.

The current code includes only one computer player that guesses a word randomly from those that correctly conform 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. There are many strategies, and no clear optimal strategy or even one that consistently beats simply choosing randomly; however, that is not the point: instead being able to code different strategies with as little repeated code is.

For extra credit, consider the following additions:

• allow the user to choose the number of letters in the secret word (and thus the dictionary to be used)
• allow the user to choose the language of the secret word (and thus the dictionary and resources to be used)
  a variety of dictionary and other word resources is available
• allow the game to end if an anagram of the secret word is guessed (i.e., all letters match, but it is not actually the secret word)
• allow the user to select a variety of requirements for the secret word (e.g., all letters must be different, there must be at least one repeated letter, or no E's allowed)
• create clearly separate GUIs for computer and human players; they should share as much code as possible and have a similar look, but differentiate the role the user plays in giving input to the model.
• provide a text-based interface to Jotto as well as the GUI, in each case though, the model should be closed to changes to these views

Grading Criteria

Your grade will be determined primarily by how easy it is to add new kinds of players to the and how easy it is to change the GUI without having to change the players model.

Note that the amount of extra credit will be in proportion to how clearly it follows the goals of your design. Contorting your main design to add in extra functionality or adding poor code that diminishes the rest of your refactoring efforts will not be rewarded. Thus, a well-tested, perfectly working program that has fewer features (but plenty of clear paths to easy expansion) is always worth more than the leaky kitchen sink. In short, to maximize your grade, you should implement enough variety in your program to clearly demonstrate that your design supports further such extensions.