1 Using the Web-CAT homework submission system
2 Methods for simple classes
3 Methods for complex data
4 Methods for collections of data

Lab 3

Goals: The goals of this lab are to learn how to follow the design recipe for designing methods in Java.

Of course, as the part of the design recipe, we will learn how to design tests for our methods and how to run them.

For a simple tutorial on how to design the tests using the tester library look at the wiki pages on the JavalibTester github site.

1 Using the Web-CAT homework submission system

For the rest of the semester we will use the Web-CAT homework submission and grading system. The WebCAT server will run your program, check whether all methods have been tested, and will also asses the code style. The graders will then make additional comments on your code, maybe checking that you have included comments, templates, etc.

In the lab today make sure every student can submit their work individually, as well as with your partner.

For the first two problems of Assignment 2 there are special rules to make sure the WebCAT server sees at least one test - please, see the updated assignment page for instructions. Submit at least two files, a file with data definitions and an ExamplesXXX.java file that defines data and incldes at least one test method, and make sure you can see ther grading report.

2 Methods for simple classes

Last week we started designing methods for the class Person that referred to the person’s Address. We have designed the method sameCityState that told us whether this person lived in the same city (and state) as the given Person.

Design the following additional methods for the classes Person and Address you have defined during the previous lab:

3 Methods for complex data

Alexander Calder was an American artist well known for his hanging sculptures called mobiles. Look up some of his work - it is really neat.

We would like to help pther artists who may want to design mobiles, so they can check ahead of the time whether their mobile will fit in the desired space (height, width, weight), and whether it will be properly balanced.

The folliwng drawing shows two mobiles:


Simple mobile      |





Complex mobile         |




           |                |

     ------+------          |

     |           |          |

     10          |          40

    red          10        green


We will restrict the mobile to two items hanging from each strut, and record for any item hanging at the end of the line its weight and its color.

We have decided on the following data representation for mobiles (the length refers to the length of the vertical string, the leftside amd rightside refer to the two parts of the strut):


             | IMobile |<---------------+

             +---------+                |

             +---------+                |

                 |                      |

                / \                     |

                ---                     |

                 |                      |

       ---------------------            |

       |                   |            |

+--------------+   +---------------+    |

| Simple       |   | Complex       |    |

+--------------+   +---------------+    |

| int length   |   | int length    |    |

| int weight   |   | int leftside  |    |

| IColor color |   | int rightside |    |

+--------------+   | IMobile left  |----+

                   | IMobile right |----+


4 Methods for collections of data

We would like to make a list of all addresses from the first problem. The data definition for a list of addresses in DrRacket was

;; A [Listof Addresses] is one of

;; -- empty

;; -- (cons Address [Listof Addresses])

This corresponds to the following class diagram:


           |                     |

           v                     |

      +---------+                |

      | ILoAddr |                |

      +---------+                |

          / \                    |

          ---                    |

           |                     |

    --------------------         |

    |                  |         |

+----------+   +---------------+ |

| MtLoAddr |   | ConsLoAddr    | |

+----------+   +---------------+ |

+----------+ +-| Address first | |

             | | ILoAddr rest  |-+

             | +---------------+



      | Address      |


      | String city  |

      | String state |


In Java, the class that represents the empty list must specify the type of list it will be - because it needs to refer to the common interface that represent both empty and nonempty lists of the given type.

We may compute the total cost of a list of books, count the number of vegetarian offerings in a list of menu items, and see if there are dangerous animals in a list of Zoo animals. These methods are specific for the type of data included in the list and depend on the type of data contained in the list.

DrRacket only realizes that we are asking whether a book is vegetarian when it encounters a wrong type of list (or just a wrong type of item within a list) at the time the program is running and the function is invoked. Static typing in Java detects this problem at the compilation time, but we pay the price by defining separate classes for representing empty lists for every type of list we deal with.

Note: Later in the course we will learn how to abstract over this code repetition.

For the last two problems you will need to use the following method defined in the class String:

// compare lexicographically this String with the given String

// produce int < 0 if the first one is before the second

// produce 0       if the two Strings are the same

// produce int > 0 if the first one is after the second

int compareTo(String that);