Objects First With Java - Solutions

|Exercise 9.1 |
|The project no longer compiles. The print method tries to access |
|the private fields of the Item class, which is not accessible from|
|subclasses. This can be corrected by creating and using accessor |
|methods instead. |
|If we try to compile after these modifications it still does not |
|work. This time it is in the compilation of the Database class |
|that it fails, because it is trying to invoke the print() method |
|on a variable of type Item. But Item has no longer declared a |
|method called print() and hence it fails. |
|Exercise 9.2 |
|The print method in the Item class is never called. If the object |
|is a CD the print method in the CD class is called. If the object |
|is a video the print method in the Video class is called. This is |
|because the dynamic types of the items are used. |
|Exercise 9.3 |
|Yes, it behaves as expected by first calling the print method from|
|the Item class and then calling the print method in the actual |
|class (dynamic type). |
|One problem is that you can't enforce the call to the super class'|
|print method. This means that if you want to create new subclasses|
|you must remember to call super.print(). |
|Another problem is that you can't modify the order of which the |
|different things are printed out. This is discussed further in |
|exercise 9.8. |
|Exercise 9.4 |
|Add this line to the beginning of the print() method in the Video |
|class: |
|System.out.print("Video: "); |
|And this line in the beginning of the CD class: |
|System.out.print("CD: "); |
|Exercise 9.5 |
|The toString() method can be found on the class Object. It has no |
|parameters and the return type is String. |
|Exercise 9.7 |
|The print() method in the CD class: |
|public void print() |
|{ |
|System.out.print("CD: " + artist + ": "); |
|super.print(); |
|System.out.println(" tracks: " + numberOfTracks); |
|} |
|The print() method in the Item class: |
|public void print() |
|{ |
|System.out.print(title); |
|if(getOwn()) { |
|System.out.println("*"); |
|} else { |
|System.out.println(); |
|} |
|System.out.println(" " + playingTime + " minutes"); |
|System.out.println(" " + comment); |
|} |
|Exercise 9.8 |
|Make all the fields in the Item class protected instead of |
|private. |
|Then modify the method in the CD class to look like this: |
|public void print() |
|{ |
|System.out.print("CD: " + artist + ": "); |
|System.out.print(title); |
|if(getOwn()) { |
|System.out.println("*"); |
|} else { |
|System.out.println(); |
|} |
|System.out.print(" " numberOfTracks + " tracks, "); |
|System.out.println(" " + playingTime + " minutes"); |
|System.out.println(" " + comment); |
|} |
|Exercise 9.9 |
|Download: zuul-with-transporter.zip |
|Exercise 9.10 |
|To implement a Monster and a Player class in the Zuul project it |
|would probably make sense to have a common superclass (Character) |
|that contains the common behaviour of the two classes. |
|Exercise 9.11 |
|It depends... you could argue for all of the inheritance |
|relations. Which one to choose depends on the current |
|implementation and (if you know) which features you plan to |
|implement in the near future. |
|If an Item is a superclass of a Character, it would allow you to |
|treat all Characters as Items. This means that a Character could |
|pick up another Character which might make sense in some |
|scenarios. |
|If Character is a superclass of Item, you can treat all Items as |
|Characters. If we define Characters as something that can move |
|around, this would allow for items to move around if that is |
|desired. |
|If the two classes are siblings and have a common superclass |
|(Thing?), you could do a combination of the above solutions. This |
|could allow a Character to pick up Things (which means you can |
|pick up both Items and Characters) and it could also allow for all|
|Things to move around (again, this also applies to Item and |
|Character). |
|If you don't consider Item and Character to have anything in |
|common you could have no inheritance relations between Item and |
|Character at all. |
|Exercise 9.12 |
|Because type-checking is done on the static type of dev (which is |
|Device) the method getName() must be defined in Device. |
|Exercise 9.13 |
|To actually execute a method dynamic method lookup is used. This |
|means that the it is the method on the Printer class that will be |
|called, because the dynamic type of dev is Printer. |
|Exercise 9.14 |
|Yes, it will compile. |
|The toString() is implemented in the class Object from the Java |
|library. The Object class is always a superclass of all other |
|classes. Hence, when you execute it is the toString as defined in |
|the class Object that will be called and the return value assigned|
|to the String s. |
|Exercise 9.15 |
|Yes, this will compile. |
|The System.out.println() method can take an Object as argument and|
|as argued in 9.14 Student is a subclass of Object. |
|Exercise 9.16 |
|Yes, it compiles. |
|It prints out all the names of the students in the list. |
|It will run through all the items in the list and call the method |
|System.out.println(it.next()). This method invokes the toString() |
|of the item - which, because of dynamic method lookup, will call |
|the toString() method in the Student class. |
|Exercise 9.17 |
|D must be a subclass of T |
|T x = new D(); |