CPSC 170 Lab 3: Multidimensional Arrays, Array Lists, and Inheritance

Magic Squares

One interesting application of two dimensional arrays is magic squares. A magic square is a square matrix of numbers in which the sum of every row, every column, and both diagonals is the same. Magic squares have been studied for many years, and there are some particularly famous magic squares. In this exercise you will write code to determine whether a square is magic.

The file Square.java contains the shell for a class that represents a square matrix. It contains headers for a constructor that takes the size of the square and a scanner to read from, plus headers for methods to read values into the square, print the square, find the sum of a given row, find the sum of a given column, find the sum of the main (or other) diagonal, and determine whether the square is magic.

The file SquareTest.java contains the shell for a program that reads input for squares and tells whether each is a magic square. Follow the comments to fill in the remaining code, but take it a piece at a time as follows:

• First, fill in code for the constructor and the printSquare method in the Square class. Then, add code to SquareTest just to read and print each square. (Note that the other methods in the Square class have dummy return values so it will compile.) Compile and run your program with the file magicData.txt to be sure you're reading all 7 squares correctly.
• Now, add code to compute and print the sums of the rows and run your program again to make sure this is working correctly.
• Now, add code to compute and print the sums of the columns and the sums of the diagonals, testing as you go.
• Finally, write the magic method and indicate whether each square is magic. You should find that the first, second, and third squares in the input are magic, and that the rest (fourth through seventh) are not. Note that the -1 at the bottom tells the test program to stop reading.

ArrayLists

The file Card.java contains a basic representation of a playing card. The file PileOfCards.java contains the stub code for a class that manages a collection of cards. This is very similar to the array of circles that we created in class. The major difference is that you will be implementing PileOfCards using an ArrayList instead of an array. This means that you don't have to worry (too much) about managing the way the collection is stored (you do not have to double the size of the ArrayList). Instead you are just going to use the predefined interface of the ArrayList to help manage the data for you.

1. The code has been commented in Javadoc style. The Javadoc Document Generator (described in Appendix I of the textbook) generates a web page (HTML code) from the Javadoc comments in the source code. Do the following to generate Javadoc web page for the Card class.
   1. In Eclipse, choose Project, then Generate Javadoc.
   2. In the Javadoc generation window, be sure that the Javadoc command field contains /usr/local/jdk1.6.0_01/bin/javadoc. If it doesn't edit it.
   3. In the "select types for which javadoc will be generated" choose Labs, then lab3. Check Card and PileOfCards.
   4. Click on Finish.
   5. Now in the File Navigator panel (on the left side of the eclipse window) under the Labs project there should be several new folders that begin with doc. Inside the doc folder double click on index.html to open the java documentation that you just generated.
   6. To see the documentation for the Card and PileOfCards classes, click on the links.
   Make note of the following:
   • There are multiple places that identify the lineage of PileOfCards. In this case, it is pretty simple - it is a child of java.lang.Object. However, in more complicated objects, this document would tell you the entire list of what other classes this class is descended from.
   • Along the same lines, notice that there is a listing of the methods that this object has inherited (from Object). Recall: the Object class has a toString method. Why does pileOfCards not inherit the toString method from Object?
   • Some of the comments have questions - you should answer them before writing any code. A good practice to get into is to understand the design of a class and how it works as much as possible before you try to implement it. (It helps to have the comments and the skeleton fleshed out like this). Doing this not only clarifies the tasks ahead for you, it also makes it easier to verify that your code will work properly, and saves you from recoding portions of your program as you redesign on the fly.
2. Implement the PileOfCards class according to the specifications in its JavaDoc.
3. If you have thought about it correctly, you should be confident that PileOfCards is free of logic and run-time errors. If you are not confident, take a few moments to think about where you may have gone wrong and convince yourself that it is correct. Make any changes that you feel are necessary.
4. If you skipped over step 3, because there was nothing to type, you'll regret it in the long run - I'm serious - stop and think about your code for a second.
5. When you are confident that your code is correct, write a text-based driver program to verify that your PileOfCards code works correctly. (Make sure that this program will convince me! P.S. there is nothing "random" about this program). The output of your program should include statements of what condition is being checked, the anticipated outcome of this statement and the actual outcome of this statement. It is not acceptable for the PileOfCards class to generate any run-time errors - all "bad" conditions should be gracefully dealt with.
6. Write a graphical driver program that interacts with a pile of cards. The file CardGame.java contains a simple stub for a JFrame that contains a CardPanel, which is a JPanel. You will need to update the CardPanel class with the following changes:
   • Add a pile of cards containing one of each of the cards that can be created. (i.e. a complete deck)
   • Add to the paintComponent method code that displays the image of the card on the top of the pile. The file GPLcards.tgz contains the images used by the card class. You will need to untar the file in your Labs directory (tar -xzf GPLcards.tgz). Verify that a new directory (GPLCards) was created in Labs and that the Card class is looking in the correct location for the files.
   • Add a button that, when pressed, removes the top card from the pile and updates the display.
   • After all the cards have been removed, if the user presses the button again, the program should display a message dialog indicating that there are no more cards.

Inheritance

The file Dog.java contains a declaration for a Dog class. Save this file to your directory and study it -- notice what instance variables and methods are provided.

The file DogTest.java contains a simple driver program that creates a dog and makes it speak. Study DogTest.java, save it to your directory, and then run it to confirm what it does.

The file Yorkshire.java contain declarations for a class that extends Dog. Save and study this files as well. Modify DogTest.java to add statements to add and print a Yorkshire (also make it speak).

The file Labrador.java also extends the Dog class. However, note that the Labrador constructor takes two parameters: the name and color of the labrador, both strings. Notice that this class contains an error:

Implicit super constructor Dog() is undefined

Fix the problem and then modify DogTest.java to create and make the Dog, Labrador, and Yorkshire all speak.

Add code to DogTest.java to print the average breed weight for both your Labrador and your Yorkshire. Use the avgBreedWeight method for both. Look at the error that you get. Figure out what is wrong and fix the problem by adding the needed code to the Yorkshire class.

Hand In: Tar your lab directory and e-mail it to your instructor with cpsc170 lab3 in the subject.