Working with Inheritance practice questions

Worked examples for Working with Inheritance

1. Question 1

   What is the output of the following program? ```java public class Main { public static void main(String[] args) { Base b = new Kid(); System.out.println(b.v + " " + b.v()); } } class Base { int v = 1; int v() { return v; } } class Kid extends Base { int v = 2; int v() { return v; } } ```

   1. A. 1 2Correct answer

      Fields don't override, so b.v resolves by the reference type Base (1), while methods do, so b.v() runs Kid's override and reads Kid's own field (2) (JLS 8 §8.3, §15.12.4.4).

   2. B. 2 2

      This assumes fields override like methods; field access resolves by the reference type, giving Base's 1.

   3. C. 1 1

      The field half is right, but methods do override, so the call reaches the subclass version and its own field.

   4. D. 2 1

      Exactly backwards: field access is resolved by the reference type, while method dispatch uses the runtime type.

   Explanation

   Fields don't override — b.v resolves by the REFERENCE type Base: 1. Methods do — b.v() dispatches to Kid's override, which reads Kid's own v field: 2. Same name, opposite resolution rules, side by side.

2. Question 2

   What is the output of the following program? ```java public class Main { public static void main(String[] args) { System.out.println(Util.tag() + "-ok"); } } interface Util { static String tag() { return "u"; } } ```

   1. A. u-okCorrect answer

      Correct: Java 8 allows a static interface method with a body, and calling it via the interface name Util.tag() returns "u", concatenated to "u-ok" (JLS 8 §9.4.3).

   2. B. Compilation fails because interfaces cannot declare static methods

      This reflects the pre-Java-8 rule; since Java 8 interfaces may declare static methods, so there is no compile error.

   3. C. Compilation fails because tag() has a body

      A static interface method is permitted to have a body in Java 8, so its body does not cause a compile failure.

   4. D. null-ok

      tag() returns the literal "u", not null, so the concatenation produces "u-ok", not "null-ok".

   Explanation

   Java 8 interfaces may declare static methods WITH bodies (`Compilation fails because interfaces cannot declare...` and `Compilation fails because tag() has a body` describe the Java 7 rules). Called via the interface name, Util.tag() returns "u", concatenated to "u-ok".

3. Question 3

   What is the output of the following program? ```java public class Main { public static void main(String[] args) { System.out.println(new Chess().name()); } } abstract class Game { Game() { System.out.print("G"); } abstract String name(); } class Chess extends Game { Chess() { System.out.print("C"); } String name() { return "chess"; } } ```

   1. A. CGchess

      Reverses constructor order; the implicit super() runs the Game constructor first, printing "G", then the Chess body prints "C", so the output is not "CGchess".

   2. B. Compilation fails because an abstract class cannot have a constructor

      Abstract classes cannot be instantiated directly but may have constructors, which run via super() when a concrete subclass is built, so there is no compile error.

   3. C. GCchessCorrect answer

      Correct: Chess's implicit super() runs Game's constructor first, printing "G", then Chess's constructor prints "C", then name() returns "chess", giving "GCchess" (JLS 8 §8.8, §12.5).

   4. D. chess

      Ignores the constructor output; both the Game and Chess constructors print before name() is called, so G and C precede "chess".

   Explanation

   Abstract classes can't be instantiated directly but absolutely may have constructors (`Compilation fails because an abstract class cannot...` is wrong) — they run via super() when a concrete subclass is built. Chess's implicit super() prints G first, then C, then name() returns "chess".

4. Question 4

   What is the result of compiling the following program? ```java public class Main { public static void main(String[] args) { new Job(); System.out.println("ok"); } } interface Task { void run(); } class Job implements Task { } ```

   1. A. ok

      The implementing class never compiles, so the program cannot print anything.

   2. B. It compiles because run() is never called

      A concrete class must implement every abstract method whether or not anyone calls it.

   3. C. Compilation failsCorrect answer

      run() has no default so it is abstract, and a concrete class implementing the interface must provide it: "Job is not abstract and does not override abstract method run()" (JLS 8 §8.1.1.1).

   4. D. An exception is thrown at runtime

      An unimplemented abstract method is a compile-time error, not a runtime failure.

   Explanation

   run() has no default, so it is abstract — and a concrete class implementing Task must provide it whether or not anyone calls it (`It compiles because run() is never called` is wrong): "Job is not abstract and does not override abstract method run()".

5. Question 5

   What is the result of compiling the following program? ```java public class Main { public static void main(String[] args) { new Disk().read(); } } class Reader { void read() throws java.io.FileNotFoundException { System.out.println("r"); } } class Disk extends Reader { void read() throws java.io.IOException { System.out.println("d"); } } ```

   1. A. Compilation failsCorrect answer

      Correct: Disk's read() declares IOException, the superclass of Reader's FileNotFoundException, which broadens the checked exceptions an override may throw, so it fails to compile (JLS 8 §8.4.8.3).

   2. B. d

      Assumes the override runs, but broadening the thrown checked exception makes it a compile error, so "d" is never printed.

   3. C. It compiles because both exceptions are related

      Being related is not sufficient; an override may narrow but never broaden checked exceptions, and this one broadens, so it does not compile.

   4. D. r

      Even ignoring the compile error, the call targets Disk's read(), not Reader's, so "r" would not print; the program does not compile at all.

   Explanation

   An override may NARROW the checked exceptions but never BROADEN them: IOException is the superclass of FileNotFoundException, so Disk's read() declares more than callers of Reader were promised — compile error. The reverse (parent IOException, child FNFE) would be fine.

6. Question 6

   What is the result of compiling the following program? ```java public class Main { public static void main(String[] args) { System.out.println("ok"); } } final class Rock { } class Pebble extends Rock { } ```

   1. A. ok

      This ignores that Rock is final; extending a final class is rejected at the subclass declaration, so "ok" never prints.

   2. B. Compilation failsCorrect answer

      Correct: a final class cannot be extended, so declaring Pebble extends Rock is a compile error ("cannot inherit from final Rock") (JLS 8 §8.1.1.2).

   3. C. It compiles because Pebble is never instantiated

      The error is reported at the class declaration regardless of whether Pebble is ever instantiated, so non-use does not save it.

   4. D. An exception is thrown at runtime

      This is a compile-time error at the declaration, so the program never runs to throw anything at runtime.

   Explanation

   A final class cannot be extended, period — whether or not the subclass is ever used (`It compiles because Pebble is never instantiated` is wrong). "cannot inherit from final Rock" is reported at the declaration itself.

7. Question 7

   What is the result of compiling the following program? ```java public class Main { public static void main(String[] args) { Limits.MAX = 20; System.out.println(Limits.MAX); } } interface Limits { int MAX = 10; } ```

   1. A. Compilation failsCorrect answer

      Every interface field is implicitly public static final, so assigning to it is "cannot assign a value to final variable" (JLS 8 §9.3).

   2. B. 20

      The assignment is rejected while compiling, so the constant is never changed to a new value.

   3. C. 10

      Merely reading the constant would print 10, but the attempted assignment stops the program from compiling.

   4. D. An exception is thrown at runtime

      Assigning to a final variable is a compile-time error, not a runtime one.

   Explanation

   Every interface field is implicitly public static FINAL — a constant. Assigning to Limits.MAX is "cannot assign a value to final variable". Reading it would print 10.

8. Question 8

   What is the output of the following program? ```java public class Main { public static void main(String[] args) { System.out.println(new Car().start()); } } interface Engine { default String start() { return "vroom"; } } class Car implements Engine { } ```

   1. A. Compilation fails because Car does not implement start()

      Assumes an implementing class must supply a body for every interface method. A default method is inherited automatically, so Car needs no start() of its own and this compiles.

   2. B. vroomCorrect answer

      Correct: Car inherits Engine's default start() with no override, so new Car().start() runs the default and returns "vroom" (JLS 8 §9.4.3).

   3. C. Compilation fails because interface methods cannot have bodies

      This was the pre-Java-8 rule. Since Java 8 an interface method marked default may carry a body, so there is no compile error here.

   4. D. null

      The inherited default returns the literal "vroom", not null; a return value is present, so this is wrong.

   Explanation

   New in Java 8: an interface may provide a DEFAULT method with a body (`Compilation fails because interface methods...` is the Java 7 rule). Implementing classes inherit it automatically, so Car needs no implementation (`Compilation fails because Car does not implement...`) — new Car().start() runs the default: "vroom".