UW CSE143 Exam

CSE143 Summer 2004
Midterm Exam #1
Multiple choice questions: 2 pts. each

1. What is the correct signature for the commonly recommended method toString?
A. public static String toString();
B. public String toString(String aString);
C. public void toString(String aString);
D. public String toString();

2. What is the correct signature for the commonly recommended method main?
A. public static void main ();
B. public int main(String aString);
C. public static void main(String[] strings);

3. One reason for using a Comparator rather than Comparable is...
A. The objects to be compared are of different types
B. The objects to be compared are in a class that cannot be modified
C. The objects to be compared are referred to by variables marked final
D. A Comparator is more efficient

4. Suppose a method has this signature in class A: private int myMethod(String x) {...
If class B extends A, and in B you define: public int myMethod(String x) {...
then this is an example of
A. Overriding
B. Overloading
C. Neither (but still valid)
D. Neither (but invalid)

5. Suppose a method has this signature in class A: protected int myMethod(String x) {...
If class B extends A, and in B you define: public int myMethod(int x) {...
Then this is an example of
A. Overriding
B. Overloading
C. Neither (but still valid)
D. Neither (but invalid)

6. Supppose in a class B you define both public int myMethod(String x) {...
as well as public String myMethod(String x) {...
Then this is an example of
A. Overriding
B. Overloading
C. Neither (but still valid)
D. Neither (but invalid)

7. One typical reason for making a class abstract instead of concrete is
A. it is not known in advance what methods are needed for the class
B. it is known that a certain method must exist but it is uncertain how to implement it
C. only abstract classes can have protected methods

8. One typical reason for defining an interface instead of an abstract class is
A. the classes that will implement this interface already extend some class
B. interfaces can define instance variables, which abstract classes cannot
C. abstract classes cannot have protected methods
D. using new, you can create objects of an interface, but can't do so for abstract classes

9. One typical reason for defining an abstract class instead of an interface is
A. the classes that will extend this abstract class already implement some interface
B. abstract classes can define constructors
C. abstract classes don't have to have names beginning with I;
D. using new, you can create objects of an abstract class, but can't do so for interfaces

10. Suppose this statement compiles without error in a Java program:
Building b = new RanchHouse(numRooms);
Which of the following could not be true?
A. Building is an interface
B. Building is an abstract class
C. Building is a superclass of RanchHouse
D. RanchHouse is a superclass of Building

11. Suppose you see this statement in a Java program which compiles without error:
super.fixUp( );
What must be true?
A. This must be the first line of a constructor
B. This must be in a constructor, though not necessarily the first line
C. This must be the first line of whatever method it is in (not necessarily in a constructor)
D. None of the above

12. When referring to something the compiler can check, we use the term _______________.
A. invariant
B. final
C. static
D. dynamic

13. When referring to something that can only be determined at run-time (i.e., when the program executes), we use the term _________________
A. invariant
B. final
C. static
D. dynamic

14. Here is the beginning of a method:
private int countHits(int hLimit) {
    if (hLimit > LIMIT) {
       throw new IllegalArgumentException("hLimit exceeded");
    }...

If the programmer choose to use the assert statement instead of an exception, what would be a correct substitution?
A.
private int countHits(int hLimit) {
    if (hLimit > LIMIT) {
       assert("hLimit exceeded");
    }...
B.
private int countHits(int hLimit) {
    assert hLimit > LIMIT: "hLimit exceeded";
   ...
C.
private int countHits(int hLimit) {
    assert hLimit <= LIMIT: "hLimit exceeded";
   ...

15. The following statement is found in a comment describing a method: "the value returned may be an empty string but will not be null unless the second parameter has a negative value." Such a comment is an example of:
A. both a precondition and a postcondition
B. a precondition (only)
C. a postcondition (only)
D. a class invariant

16. Consider the following line of code:

System.out.println("Pet # i:" + ((Dog) pets[i]).toString());

Assume this statement compiles without error. Several things could cause an exception to occur when the program runs. List three such things: explain briefly what would cause the error and what the Java exception would be. Do not list more than three. (Each is worth 1 M.C. question)

    1.

    2.

    3.

17. (worth 3 M.C. questions) Draw a diagram to show the objects and identifiers that exist after these lines of code have executed, using the style and labeling conventions shown in class:

ArrayList list1, list2, list3;
list1 = new ArrayList();
list2 = new ArrayList();
String myName = "Yao";
list1.add(myName);
list2.add(myName);
list.add("Ming");
String value = (String) list.get(1);
list3 = list2;

18. Golden Glove rankings (worth 12 M.C. questions).

Most baseball players spend at least part of their time as "fielders", that is, catching and throwing balls in the "field". Records are kept of statistics like: how many games they play, how many errors they make, etc.

Write a new application (i.e., not an extension of the baseball application) that has two classes, called Player.java and Fielders.java. This application will read in a file with fielder (player) information and allow information to be retreived. Like the project files, this file is derived from the MLB web page and has a similar format (a sample is on the handout). Specs for DelimitedTextFile are on the handout.

Player.java already exists and is given. You are free to modify Player.java if appropriate -- if you do so, write your changes directly on the existing code.

You should write Fielders.java from scratch (use a blank page at the end of this booklet). It must implement the IFielders interface, for which a Java is given on a handout. You may write additional classes if needed, but in the interests of time, keep your solution short and compact. You do not need to write a main method.

Do these instructions seem incomplete? They will make more sense after you've looked at IFielders.java to see what you need to implement, and Player.java to see what is already there.