Feedback Form
|
|
Start of Tutorial > Start of Trail > Start of Lesson |
Search
Feedback Form |
Check out these pages to find out the most interesting features of the Game and Player programs and investigate the code that implements them.
This section analyzes the design of classes that comprise the Game and Player applications, including discussions on why we made certain decisions and the tradeoffs we made in doing so. In particular this section focuses on decisions we made about subclassing, using interfaces, using anonymous and inner classes, and how we arranged the classes and interface in packages.
[PENDING: this section is under construction] A collection of box diagrams show you the classes that implement and control the various elements in the GUI's of both the Game and the Player applications.
Both the Game application and the Player create and use many threads. When different threads access and change the same data concurrently, the threads must be synchronized to avoid errors. Additionally, some threads depend on state changes that are affected in other threads. In cases such as this, the threads involved must coordinate.
The Player and the Game communicate in two different ways: the Game broadcasts status information and the Player makes requests of the Game. This talks about the JDK APIs that we chose to accomplish these feats of communication and why we chose them. Then the section goes on to describe the classes and the code that participate in the communication between the Game and the Player.
To protect against cheating, the Game signs all BINGO cards played in each game. When a Player claims to have a winning card, the Game verifies the signature on the card to make sure that its was signed by this Game for the current game.
[PENDING: this section is under construction]
Like other applications, the Player and the Game applications contain UI elements that let the user tweak various program settings. (Program settings are often called parameters or properties.) This section looks at the code in the Player that manages the application's settings. The discussion takes a top-down approach and looks at each layer in the code that takes a part in managing the program settings, from the user elements, to how the various settings affect the play of the game, to how the application uses the JDK's Properties mechanism to remember settings between invocations.
[PENDING: this section is under construction]
|
|
Start of Tutorial > Start of Trail > Start of Lesson |
Search
Feedback Form |
Copyright 1995-2005 Sun Microsystems, Inc. All rights reserved.