Due: 10:00 AM, Monday, 10/06/08

This assignment builds on Program 3. As before, this is individual effort (don't copy!). Your system should be organized as follows:

1. A package named Games. In the package are these classes:
   1. Game. This is an abstract class that can be extended to create classes for specific games. The Game class and its methods should be public, but its variables (except for its instance of Board) should be private.
   2. Board. You should be able to use the Board class from the previous assignment with some changes. The Board class and its methods (except for equals) should be accessible only from the other classes in the package Games and any of its subclasses, but its variables should be private. The equals method should be accessible from anywhere. The main modifications that you have to make are to allow game pieces of different kinds, and to handle exceptions. For example, in checkers, pieces can be red or black, and they can be regular checkers pieces or kings, giving a total of four kinds of pieces. (You don't need to know what these mean to do this assignment.) Each kind of piece is identified by a unique code. Squares on the game board can be unoccupied or occupied by a single piece of some kind. Use the following codes to indicate the occupancy of a square:
      0: unoccupied
      1: red checker
      2: black checker
      3: red king
      4: black king
   3. Checkers, which must be a direct subclass of Game. The Checkers class and its methods should be public, but its variables should be private.
2. A class named TestCheckers containing a main program that thoroughly tests the Checkers and Board classes, including catching exceptions thrown by Board methods. TestCheckers should not be in the package Games.

The classes Game, Board and Checkers must satisfy the interfaces given below; that is, you are not free to change the name, type, or behavior of the given methods.

Your grade will be based on how well you design and implement the code (including whether you followed the directions in 1.1., 1.2, 1.3, and 2. above), on good programming practices, and on thorough testing. Coding guidelines for Java programs are posted here.

• The first constructor creates an instance of a game on an nXn board with all squares empty.
• The second constructor is a copy constructor.
• The remove(int row, int col) method will remove the piece from the square (row,col).
• The place(int piece, int row, int col) method will place a piece (whose code is given by the first parameter) on the square (row,col) if the square is empty.
• The show(int row, int col) method will return a value indicating the kind of piece on the square (row,col) if the square is occupied, or a value indicating the the square is unoccupied.
• The equals(Game agame) method overrides the Object method equals(), returning true if and only if this instance of Game equals the instance agame. Here, equality does not mean they have the same reference. It means that the values of each variable in the two games is the same.

• The first constructor creates an instance of an nXn board with all squares empty.
• The second constructor is a copy constructor.
• The remove(int row, int col) method will remove the piece from the square (row,col). If the square is empty then an exception is thrown.
• The place(int piece, int row, int col) method will place a red or black checker or king (depending on the value of piece) on the square (row,col) if the square is empty. If it is occupied then an exception is thrown.
• The show(int row, int col) method will return a value indicating the kind of piece on the square (row,col) if the square is occupied. or a value indicating that the square is unoccupied. If row and col are not legal values then an exception is thrown.
• The equals(Board gameboard) method overrides the Object method equals(), returning true if and only if this instance of Board equals the instance gameboard. Here, equality does not mean they have the same reference. It means that the contents of each square in the two boards is the same.

• The first constructor initializes the instance of the new object with the board set up for the start of a checkers game. (If you don't know checkers, I can show you the starting positions of a game.)
• The second constructor is a copy constructor.
• The remove(int row, int col) method calls the remove method from Board to implement the abstract remove method in Game. Any exceptions thrown by the remove method in Board are thrown.
• The place(int piece, int row, int col) method calls the place method from Board to implement the abstract place method in Game. Any exceptions thrown by the place method in Board are thrown.
• The show(int row, int col) method calls the show method from Board to implement the abstract show method in Game. Any exceptions thrown by the show method in Board are thrown.
• The move(int fromrow, int fromcol, int torow, int tocol) method will move the piece from (fromrow,fromcol) to (torow,tocol) if (fromrow,fromcol) is occupied and (torow,tocol) is not. If those conditions are not satisfied the board is not changed. Any exceptions are thrown.
• The display() method will output a picture of the board. As before, it can be very simple, but now it should indicate whether a square is empty or contains a red or black checker or king.
• The equals(Checkers agame) method overrides the Object method equals(), returning true if and only if this instance of Checkers equals the instance agame. Here, equality does not mean they have the same reference. It means that the values of each variable in the two games is the same.

The main method in TestCheckers should catch exceptions thrown by methods in Board and Checkers, and it should create several instances of Checkers.

Add comment documentation to your program (all four classes) and use javadoc to extract the documentation into an HTML file. Include a javadoc comment for each class and each method. The class comment should include your name and the date (use the @author tag). Method comments should briefly describe the purpose of the method, its arguments, and what, if anything, it returns (using @param and @return as appropriate).

The physical location of the javadoc comments is critical. A class comment must immediately precede the line containing the keyword class, and method comments must immediately precede the method.

When you have commented your source files, run javadoc to create the .html files and view them in a browser of your choice.

• Turn in a hardcopy printout of your java source files TestCheckers.java, Game.java, Board.java, Checkers.java, and any other java source files your program uses, including any Exception classes you create, and a printout of your test runs. Do not give me a copy of the javadoc.html files.
• All Java programs will be submitted by copying (or ftping) them to a specially designated directory in AFS. Each person in the class has a subdirectory which has the same name as your login in /afs/cu/class/cs242/fa08

  Within this individual directory, create a subdirectory named p5. Copy only the source files into this directory, not class files or javadoc files. So, for example, if your login name was smithjd then the four files TestCheckers.java, Game.java, Board.java, Checkers.java, and any other java source files your program uses, including any Exception classes you create should be copied to /afs/cu/class/cs242/fa08/smithjd/p5. These directories have permissions set so that no one other than yourself and Prof. Lynch can read the files. You may, of course, use whatever operating system and compiler you wish to develop your code, but the version you turn in, both hardcopy and the files submitted to AFS, must compile and run under JDK installed in the Clarkson ITL (our lab room).

• Correct execution. The program must follow all the specifications above. The hardcopy of your program's execution should clearly demonstrate that it does. You may want to turn in hardcopy of more than one execution.
• Correct implementation. The program must follow all the design requirements above, in particular the interfaces of the classes and their access attributes.
• Error checking. You have to figure out what kinds of errors your program should check for, and how it should handle them, within the constraints listed above. The errors mentioned above are not the only errors that can occur. The hardcopy of your execution should include examples of these error handling capabilities.
• Readability of the code: commented and well-structured, so that it is clear what the code is doing. Use an accepted programming style. The style of the text is fine, or you can follow the Code Conventions. Whatever you do, be consistent.
• Appearance of the output. At this point, we haven't covered any of the ways to generate really nice looking output, but the display method should produce a picture of the board with all the rows and columns lined up nicely, and any error messages should be well-formatted and easy to read.
• Timely submission of your program. All hardcopy must be turned in by the deadline. Late programs will not be accepted. Printouts submitted electronically will be ignored.