Design Overview

See:
          Description

Packages

 

Design Overview

Note: The author chose to "over design" this solution in order to demonstrate several valuable design techniques. The solution has far more classes than it really needs. As a result the solution has the advantage that each class can focus on just one specific part of the solution and it is easy to understand, yet the overall solution requires coordination or "orchestration" of a number of classes and understanding how this coordination takes place requires some study.

Since Hangman is an interactive game, the central architecture is event-driven. However, it also uses client-server architecture to solve the problem of obtaining a hidden word.

Importantly the design has been decomposed in order to separate four major aspects: user interface, network communication, game logic, and the data model of the playing board. 

Class name
Purpose
Game game flow control and logic
NetClient client (game) side of network communication
WordServer server side of network communication - provides hidden words
Board the data model of the playing board
HangmanUI specification for the user interface
   
SimpleUI and SwingUI implementations of the user interface
HangmanApp the "driver" which starts the entire application
The HangmanApp handles the command line parameters then makes instances of the board, game logic, and user interface. Before actually begining game play, NetClient will interact with WordServer to obtain a hidden word. Once HangmanLogic starts playing the game, the user interface class will iteract with the user to obtain the player's move and display the results, and the Board class will store the hidden word, guessed letters, and other data about the state of the game.

Word Server is run as a separate application. It simply picks a random word from a list and provides it to whoever asks for it. There may be different servers running on different computers, in theory each could have a different word list. For example on server might have words related to sports, and another might have words related to nutrition. The user has the chance to specifiy which Word Server they would like to use when they start the application. The words themselves are stored in an external file to make it easy to add more words.

The user interface is entirely separate from the game logic thus making it easy to modify or create alternate "front ends" in the future. HangmanUI is a Java Interface which provides only method definitions. Two specific versions of the user interface are provided: SimpleUI is a console-based user interface, and SwingUI uses the Java Swing classes.

An additional flexibility is the user may specify which user interface to run at execution time. By using Java Reflection, HangmanApp takes the class name provided by the user and loads the desired class. Thus developers may write their own class which implements the HangmanUI interface and it will "plug in" to the rest of the application without recompiling anything.

III.  Design Issues

Issue #1:  Should choosing a random hidden word be part of Hangman or a separate application?

Alternative A: part of Hangman.

Advantages: Design is simpler.

Disadvantages: Design is less flexible.

Alternative B:  choosing a random word is a separate "server" application.

Advantages: More flexible. User may select from several available servers that provide different kinds of words. The word server could be used for other word games besides Hangman.

Disadvantages: Design is more complex.

Decision:  Alternative B. Primarily for pedagogical reasons, we chose the more flexible solution.


Issue #2: What data structure whould be used for the hidden word?

Alternative A:  An array of characters.

Advantages: Can access individual letters easily.

Disadvantages: Matching a letter requires a linear search.

Alternative B: String.

Advantages: Can use built-in functions to see if the word "contains" the guessed letter.

Disadvantages: Strings are zero-based, a common source of coding errors.

Decision: Alternative B. There are obvious advantages and no serious disadvantages relative to arrays.


Issue #3: Should the components be put into java packages?

Alternative A: Yes.

Advantages: Packaging is a convenient way to organize large projects.

Disadvantages: It makes compiling a little more complicated.

Alternative B: No.

Advantages: For instructional purposes, Dr. Dalbey would like teams to be able to swap compiled classes.  Unless there is strict adherence to a uniform naming convention, this will be difficult to accomplish. Using no packages would make it easier to swap classes at runtime.

Disadvantages: We lose the advantages of packaging.

Decision: Alternative B. No packages.  The pedagogical goal of swapping classes outweighs the minor benefits of packaging.



 
 

IV.  Tools

The following list of compilers and other development tools used and their version numbers:
 

Java 2 SDK Standard Edition Version 1.6

NetBeans 6.5
 
 

V.  Libraries

Only standard Java libraries are used.