Programming Concepts using Java · Quiz 1 · Sep 2024

**Answer: D** **Topic:** Web Fundamentals — *URL Format for an HTML Form Submitted via HTTP POST* ### Step-by-Step Solution **Step 1:** In HTML forms, when `method="GET"` is used, form data is appended to the URL as a query string (`?name=Application`). **Step 2:** However, when **`method="POST"`** is set, the form data is sent inside the **HTTP request body**, NOT in the URL query string. **Step 3:** Therefore, the URL in the browser remains simply **`http://127.0.0.1:5000/`**, which matches **D**. **Key Takeaway / Tip:** `POST` requests place form inputs in the request body rather than appending `?key=value` to the URL. A: **Incorrect:** Option A (

) does not satisfy the conditions derived in the step-by-step analysis for URL Format for an HTML Form Submitted via HTTP POST (correct choice: D). B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for URL Format for an HTML Form Submitted via HTTP POST (correct choice: D). C: **Incorrect:** Option C (

) does not satisfy the conditions derived in the step-by-step analysis for URL Format for an HTML Form Submitted via HTTP POST (correct choice: D). D: **Correct:** Option D (

      **Java** **Section Id :** 64065369407 **Section Number :** 8 **Section type :** Online **Mandatory or Optional :** Mandatory **Number of...) matches our derived result under URL Format for an HTML Form Submitted via HTTP POST. `POST` requests place form inputs in the request body rather than appending `?key=value` to the URL.

**Answer: C** **Topic:** Java Execution Model — *Counting Call-Stack Activation Records in Recursive Factorial* ### Step-by-Step Solution **Step 1:** In Java, an **activation record (stack frame)** is pushed onto the call stack for every method invocation, starting with `main(String[] args)`. **Step 2:** Trace the chain of method calls when `ActivationRecordExample` runs: 1. `main()` (1st activation record) 2. `factorial(5)` (2nd activation record) 3. `factorial(4)` (3rd activation record) 4. `factorial(3)` (4th activation record) 5. `factorial(2)` (5th activation record) 6. `factorial(1)` (6th activation record — base case `n == 1` returns `1`) **Step 3:** Count the total number of activation records created on the call stack: $1\text{ (for } \texttt{main}\text{)} + 5\text{ (for } \texttt{factorial(5..1)}\text{)} = 6$, which matches **C**. **Key Takeaway / Tip:** Never forget to count the activation record for `main()` in addition to the 5 recursive calls `factorial(5)` down to `factorial(1)`! A: **Incorrect:** Option A (2) does not satisfy the conditions derived in the step-by-step analysis for Counting Call-Stack Activation Records in Recursive Factorial (correct choice: C). B: **Incorrect:** Option B (5) does not satisfy the conditions derived in the step-by-step analysis for Counting Call-Stack Activation Records in Recursive Factorial (correct choice: C). C: **Correct:** Option C (6) matches our derived result under Counting Call-Stack Activation Records in Recursive Factorial. Never forget to count the activation record for `main()` in addition to the 5 recursive calls `factorial(5)` down to `factorial(1)`! D: **Incorrect:** Option D (7) does not satisfy the conditions derived in the step-by-step analysis for Counting Call-Stack Activation Records in Recursive Factorial (correct choice: C).

**Answer: D** **Topic:** Programming Language Concepts — *Matching Inheritance, Control Link, Variable Lifetime, and Static Typing* ### Step-by-Step Solution **Step 1:** Match each programming concept (A–D) to its exact definition (I–VII): - **A. Inheritance**: Represents a relationship of implementations between a superclass and subclass $\to$ **VI** (`A-VI`). - **B. Control Link**: Dynamic link in an activation record that points to the start of the previous (caller's) activation record on the stack $\to$ **VII** (`B-VII`). - **C. Lifetime**: The duration/time during execution for which a variable remains allocated in memory $\to$ **III** (`C-III`; whereas I describes *Scope*). - **D. Static Typing**: Compile-time type checking that enables catching bugs in source code early on $\to$ **II** (`D-II`). **Step 2:** Therefore, **A-VI, B-VII, C-III, D-II** (**D**) is correct. **Key Takeaway / Tip:** Distinguish **Scope** (I: spatial region of program text where a variable is visible) from **Lifetime** (III: temporal duration during which a variable exists in memory). A: **Incorrect:** Option A (A-VI, B-IV, C-I, D-II) does not satisfy the conditions derived in the step-by-step analysis for Matching Inheritance, Control Link, Variable Lifetime, and Static Typing (correct choice: D). B: **Incorrect:** Option B (A-V, B-VII, C-I, D-IV) does not satisfy the conditions derived in the step-by-step analysis for Matching Inheritance, Control Link, Variable Lifetime, and Static Typing (correct choice: D). C: **Incorrect:** Option C (A-V, B-IV, C-I, D-II) does not satisfy the conditions derived in the step-by-step analysis for Matching Inheritance, Control Link, Variable Lifetime, and Static Typing (correct choice: D). D: **Correct:** Option D (A-VI, B-VII, C-III, D-II) matches our derived result under Matching Inheritance, Control Link, Variable Lifetime, and Static Typing. Distinguish **Scope** (I: spatial region of program text where a variable is visible) from **Lifetime** (III: temporal duration during which a variable exists in memory).

**Answer: C** **Topic:** Java Control Flow — *Do-While Loop Termination and Switch-Case Execution* ### Step-by-Step Solution **Step 1:** Trace the `do-while` loop starting with `int counter = 5;`: - Iteration 1: `counter--` $\to 4$; `4 > 0` is `true`. - Iteration 2: `counter--` $\to 3$; `3 > 0` is `true`. - Iteration 3: `counter--` $\to 2$; `2 > 0` is `true`. - Iteration 4: `counter--` $\to 1$; `1 > 0` is `true`. - Iteration 5: `counter--` $\to 0$; `0 > 0` is `false` $\implies$ loop terminates with **`counter == 0`**! **Step 2:** Next, enter `switch(counter)` with `counter = 0`: - Matches `case 0:`, prints **`counter zero`**, and immediately hits `break;` (exiting the `switch` block). **Step 3:** Therefore, the output is **`counter zero`** (**C**). **Key Takeaway / Tip:** Because `case 0:` has its own `break;` statement, execution exits the `switch` immediately after printing `counter zero` without falling through to `case 1:`. A: **Incorrect:** Option A (counter one counter two counter three counter four counter five No counter available) does not satisfy the conditions derived in the step-by-step analysis for Do-While Loop Termination and Switch-Case Execution (correct choice: C). B: **Incorrect:** Option B (counter one) does not satisfy the conditions derived in the step-by-step analysis for Do-While Loop Termination and Switch-Case Execution (correct choice: C). C: **Correct:** Option C (counter zero) matches our derived result under Do-While Loop Termination and Switch-Case Execution. Because `case 0:` has its own `break;` statement, execution exits the `switch` immediately after printing `counter zero` without falling through to `case 1:`. D: **Incorrect:** Option D (No counter available) does not satisfy the conditions derived in the step-by-step analysis for Do-While Loop Termination and Switch-Case Execution (correct choice: C).

**Answer: C** **Topic:** Object-Oriented Programming in Java — *Inheritance Hierarchy and Dynamic Method Dispatch* ### Step-by-Step Solution **Step 1:** Examine the 3-level inheritance hierarchy: `Cat extends Dog` and `Dog extends Animal`. - `Animal` defines `sound()` (`"Makes a sound"`). - `Dog` inherits `sound()`, defines `play()` (`"Plays fetch"`), and defines `guard()` (`"Guards the house"`). - `Cat` inherits `sound()` and `play()`, and **overrides** `guard()` (`"Guards the garden"`). **Step 2:** Trace `main()` where `Dog obj = new Cat();` (compile-time type `Dog`, runtime object `Cat`): 1. `obj.sound();` $\implies$ valid on `Dog` (inherited from `Animal`), prints **`Makes a sound`**. 2. `obj.play();` $\implies$ valid on `Dog`, prints **`Plays fetch`**. 3. `obj.guard();` $\implies$ dynamically dispatches to the overridden method in `Cat`, printing **`Guards the garden`**. **Step 3:** This 3-line output matches Option **C**. **Key Takeaway / Tip:** In Java, instance method calls are resolved at runtime based on the actual object type (`new Cat()`), so `obj.guard()` invokes `Cat`'s version. A: **Incorrect:** Option A (

) does not satisfy the conditions derived in the step-by-step analysis for Inheritance Hierarchy and Dynamic Method Dispatch (correct choice: C). B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Inheritance Hierarchy and Dynamic Method Dispatch (correct choice: C). C: **Correct:** Option C (

) matches our derived result under Inheritance Hierarchy and Dynamic Method Dispatch. In Java, instance method calls are resolved at runtime based on the actual object type (`new Cat()`), so `obj.guard()` invokes `Cat`'s version. D: **Incorrect:** Option D (

) does not satisfy the conditions derived in the step-by-step analysis for Inheritance Hierarchy and Dynamic Method Dispatch (correct choice: C).

**Answer: D** **Topic:** Object-Oriented Programming in Java — *Passing 'this' Reference to Another Class Constructor* ### Step-by-Step Solution **Step 1:** In `main()`, `Pizza p1 = new Pizza(); p1.orderPizza();` is called. **Step 2:** Trace `p1.orderPizza()` step by step: 1. `PizzaMaker m = new PizzaMaker(this);` passes the current `Pizza` instance (`p1`) to `PizzaMaker`'s constructor, which stores it in `m.piz`. 2. `m.preparePizza();` executes: - First prints **`Pizza prepared`**. - Then calls `piz.alarm();`, which invokes `alarm()` on `p1` and prints **`Pizza collected`**. 3. Control returns to `orderPizza()`, which executes `System.out.println("Pizza served");` and prints **`Pizza served`**. **Step 3:** Thus, the program compiles and prints `Pizza prepared`, `Pizza collected`, `Pizza served` (**D**). **Key Takeaway / Tip:** In Java, `this` is a reference to the current object and can be passed as an argument to another class's constructor or method. A: **Incorrect:** Option A (

) does not satisfy the conditions derived in the step-by-step analysis for Passing 'this' Reference to Another Class Constructor (correct choice: D). B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Passing 'this' Reference to Another Class Constructor (correct choice: D). C: **Incorrect:** Option C (

) does not satisfy the conditions derived in the step-by-step analysis for Passing 'this' Reference to Another Class Constructor (correct choice: D). D: **Correct:** Option D (

) matches our derived result under Passing 'this' Reference to Another Class Constructor. In Java, `this` is a reference to the current object and can be passed as an argument to another class's constructor or method.

**Answer: B** **Topic:** Object-Oriented Programming in Java — *Overriding Object.equals(Object obj) with Downcasting* ### Step-by-Step Solution **Step 1:** In `class Car`, `public boolean equals(Object obj)` takes a parameter `obj` of static type `Object`. - Because `Object` does not have fields `.model` or `.vin`, accessing `obj.model` directly (Options A and C) causes a **compile-time error**. - Assigning `Car c = obj;` without an explicit cast (Option D) also causes a **compile-time error** (narrowing conversion from `Object` to `Car`). **Step 2:** In **Option B**: 1. `if (obj instanceof Car)` checks that `obj` is a `Car`. 2. `Car c = (Car) obj;` explicitly downcasts `obj` to `Car`. 3. `if (this.model == c.model && this.vin == c.vin) return true;` compares the interned string literals and returns `true`. **Step 3:** Therefore, **B** is the only valid implementation. **Key Takeaway / Tip:** When overriding `equals(Object obj)`, you must first check `obj instanceof Car` and then explicitly downcast `(Car) obj` before accessing `Car`-specific fields. A: **Incorrect:** Option A (

) does not satisfy the conditions derived in the step-by-step analysis for Overriding Object.equals(Object obj) with Downcasting (correct choice: B). B: **Correct:** Option B (

) matches our derived result under Overriding Object.equals(Object obj) with Downcasting. When overriding `equals(Object obj)`, you must first check `obj instanceof Car` and then explicitly downcast `(Car) obj` before accessing `Car`-specific fields. C: **Incorrect:** Option C (

) does not satisfy the conditions derived in the step-by-step analysis for Overriding Object.equals(Object obj) with Downcasting (correct choice: B). D: **Incorrect:** Option D (

) does not satisfy the conditions derived in the step-by-step analysis for Overriding Object.equals(Object obj) with Downcasting (correct choice: B).

**Answer: D** **Topic:** Object-Oriented Programming in Java — *Constructor Chaining with super() in Subclasses* ### Step-by-Step Solution **Step 1:** In `class Publisher`, `name` is `private`, and the only constructor is `public Publisher(String nm)` (there is no no-arg default constructor `Publisher()`). **Step 2:** Analyze the consequences for `class Book extends Publisher`: - **A fails**: `new Book("TechPublisher", a)` passes 2 arguments, and without an explicit `super(nm)`, Java tries to insert `super()`, which does not exist in `Publisher`. - **B fails**: In Java, a call to `super(nm);` **must be the very first statement** inside the subclass constructor; placing `this.authors = auth;` before `super(nm);` causes a compile-time error. - **C fails**: Both because `super()` is missing and because `this.name` is `private` in `Publisher`. - **D succeeds**: `public Book(String nm, String[] auth) { super(nm); this.authors = auth; }` calls `super(nm);` on the first line and then initializes `this.authors`. **Step 3:** Therefore, **D** is correct. **Key Takeaway / Tip:** In Java, `super(...)` (or `this(...)`) must always be the **first** statement in a constructor body. A: **Incorrect:** Option A (

) does not satisfy the conditions derived in the step-by-step analysis for Constructor Chaining with super() in Subclasses (correct choice: D). B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Constructor Chaining with super() in Subclasses (correct choice: D). C: **Incorrect:** Option C (

) does not satisfy the conditions derived in the step-by-step analysis for Constructor Chaining with super() in Subclasses (correct choice: D). D: **Correct:** Option D (

) matches our derived result under Constructor Chaining with super() in Subclasses. In Java, `super(...)` (or `this(...)`) must always be the **first** statement in a constructor body.

**Answer: C** **Topic:** Object-Oriented Programming in Java — *Shallow Copy Constructor and Shared Array References* ### Step-by-Step Solution **Step 1:** Inspect the copy constructor in `class Course`: `public Course(Course c) { this.courseName = c.courseName; this.topics = c.topics; }`. - Notice that `this.topics = c.topics;` copies only the **array reference** (a **shallow copy**), so `course1.topics` and `course2.topics` point to the **exact same `String[]` array** in memory! **Step 2:** Trace the mutations in `main()`: 1. `course2.courseName = "Advanced Java";` reassigns `course2.courseName` to a new `String` object without affecting `course1.courseName` (`"Java"`). 2. `course2.topics[1] = "Abstract Classes";` mutates index `1` of the shared `topics` array, so **both** `course1.topics[1]` and `course2.topics[1]` become `"Abstract Classes"`! **Step 3:** Therefore, the two `println` statements output: `Java, Abstract Classes` `Advanced Java, Abstract Classes` which matches **C**. **Key Takeaway / Tip:** Copying an array reference (`this.topics = c.topics`) creates a shallow copy; mutating an element `course2.topics[1]` modifies the shared array seen by `course1`. A: **Incorrect:** Option A (

) does not satisfy the conditions derived in the step-by-step analysis for Shallow Copy Constructor and Shared Array References (correct choice: C). B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Shallow Copy Constructor and Shared Array References (correct choice: C). C: **Correct:** Option C (

) matches our derived result under Shallow Copy Constructor and Shared Array References. Copying an array reference (`this.topics = c.topics`) creates a shallow copy; mutating an element `course2.topics[1]` modifies the shared array seen by `course1`. D: **Incorrect:** Option D (

) does not satisfy the conditions derived in the step-by-step analysis for Shallow Copy Constructor and Shared Array References (correct choice: C).

**Answer: A** **Topic:** Object-Oriented Programming in Java — *Multi-Level super.play() Chaining and Method Overloading* ### Step-by-Step Solution **Step 1:** In `main()`, `Guitar obj = new ElectricGuitar();` creates an `ElectricGuitar` instance referenced by a `Guitar` variable. **Step 2:** Trace the two method calls: 1. **`obj.play();`**: - Dispatches to `ElectricGuitar.play()`, which first calls `super.play()` (`Guitar.play()`). - `Guitar.play()` first calls `super.play()` (`Instrument.play()`), which prints **`Play instrument`**. - `Guitar.play()` then prints **`Play guitar`**. - `ElectricGuitar.play()` then prints **`Play electric guitar`**. 2. **`obj.play("Rock Song");`**: - Since `Guitar` declares `play(String song)` and `ElectricGuitar` overrides `play(String song)` (without calling `super`), it dispatches to `ElectricGuitar.play("Rock Song")` and prints **`Play electric guitar: Rock Song`**. **Step 3:** This 4-line output matches Option **A**. **Key Takeaway / Tip:** Follow `super.play()` all the way up the inheritance chain (`ElectricGuitar -> Guitar -> Instrument`) and then unwind the print statements from top to bottom. A: **Correct:** Option A (

) matches our derived result under Multi-Level super.play() Chaining and Method Overloading. Follow `super.play()` all the way up the inheritance chain (`ElectricGuitar -> Guitar -> Instrument`) and then unwind the print statements from top to bottom. B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Multi-Level super.play() Chaining and Method Overloading (correct choice: A). C: **Incorrect:** Option C (

) does not satisfy the conditions derived in the step-by-step analysis for Multi-Level super.play() Chaining and Method Overloading (correct choice: A). D: **Incorrect:** Option D (

) does not satisfy the conditions derived in the step-by-step analysis for Multi-Level super.play() Chaining and Method Overloading (correct choice: A).

**Answer: D** **Topic:** Object-Oriented Programming in Java — *Compile-Time Type Checking on Upcast Reference Variables* ### Step-by-Step Solution **Step 1:** In `main()`, `Vehicle obj = new Car();` declares `obj` with **compile-time (static) type `Vehicle`** and runtime type `Car`. **Step 2:** Check each line: - `LINE 1`: Upcasting `new Car()` to `Vehicle` is completely legal. - `LINE 2` (`obj.startEngine();`): `Vehicle` declares `startEngine()`, so it compiles and dynamically invokes `Car.startEngine()`. - `LINE 3` (`obj.horn();`): The Java compiler checks whether `horn()` is declared in the static type **`Vehicle`**. Because `Vehicle` does **not** have a `horn()` method, **LINE 3 generates a compilation error**! **Step 3:** Therefore, **D** (`LINE 3 generates compilation error because the method horn() is not defined in the Vehicle class`) is correct. **Key Takeaway / Tip:** In Java, the compiler validates method calls using the **declared (reference) type** (`Vehicle`), not the runtime object type (`Car`). A: **Incorrect:** Option A (

) does not satisfy the conditions derived in the step-by-step analysis for Compile-Time Type Checking on Upcast Reference Variables (correct choice: D). B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Compile-Time Type Checking on Upcast Reference Variables (correct choice: D). C: **Incorrect:** Option C (

) does not satisfy the conditions derived in the step-by-step analysis for Compile-Time Type Checking on Upcast Reference Variables (correct choice: D). D: **Correct:** Option D (

) matches our derived result under Compile-Time Type Checking on Upcast Reference Variables. In Java, the compiler validates method calls using the **declared (reference) type** (`Vehicle`), not the runtime object type (`Car`).

**Answer: C** **Topic:** Object-Oriented Programming in Java — *Final Methods, Private Static Fields, and Downcasting Errors* ### Step-by-Step Solution **Step 1:** Examine `Vehicle`, `Car`, and `TransportTest` to find which statement is **FALSE** (note that the question asks *'Which of the following statements is FALSE?'*): - **Statement A is TRUE**: In `Vehicle`, `calculateFare()` is declared `final`, so trying to override it in `Car` at `LINE 1` generates a compilation error. - **Statement B is TRUE**: In `Vehicle`, `baseFare` is declared `private`, so accessing `baseFare` directly inside `Car` at `LINE 2` generates a compilation error. - **Statement C is FALSE**: At `LINE 3`, `Vehicle v1 = new Car(201);` is a valid **upcast** (a reference variable of superclass type `Vehicle` *can* refer to a subclass object `Car`), so `LINE 3` does **NOT** generate a compilation error! - **Statement D is TRUE**: At `LINE 4`, `Car c1 = new Vehicle(205);` attempts to assign a superclass object (`Vehicle`) to a subclass reference (`Car`), which generates a compilation error. **Step 2:** Since the question asks which statement is **FALSE**, **C** is the correct answer. **Key Takeaway / Tip:** Upcasting (`Vehicle v1 = new Car(201);` at LINE 3) is always valid in Java, so claiming that LINE 3 causes a compilation error is FALSE. A: **Incorrect:** Option A (

) does not satisfy the conditions derived in the step-by-step analysis for Final Methods, Private Static Fields, and Downcasting Errors (correct choice: C). B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Final Methods, Private Static Fields, and Downcasting Errors (correct choice: C). C: **Correct:** Option C (

) matches our derived result under Final Methods, Private Static Fields, and Downcasting Errors. Upcasting (`Vehicle v1 = new Car(201);` at LINE 3) is always valid in Java, so claiming that LINE 3 causes a compilation error is FALSE. D: **Incorrect:** Option D (

) does not satisfy the conditions derived in the step-by-step analysis for Final Methods, Private Static Fields, and Downcasting Errors (correct choice: C).

**Answer: A** **Topic:** Object-Oriented Programming in Java — *Interfaces, Abstract Classes, and Concrete Subclasses* ### Step-by-Step Solution **Step 1:** Trace the type hierarchy: - `interface Flyable` defines a `default void fly()` (`"Flying"`) and an abstract `void takeOff()`. - `abstract class Bird implements Flyable` overrides `fly()` (`"Flying high"`) and leaves `takeOff()` abstract (inherited from `Flyable`). - `class Eagle extends Bird` implements `takeOff()` (`"Taking off"`). **Step 2:** In `main()`, `Bird obj = new Eagle();` is valid (an abstract class reference `Bird` can point to a concrete subclass instance `Eagle`), and since `Bird` implements `Flyable`, both `obj.fly()` and `obj.takeOff()` are known at compile time on `Bird`: - `obj.fly()` calls `Bird.fly()` $\implies$ prints **`Flying high`**. - `obj.takeOff()` calls `Eagle.takeOff()` $\implies$ prints **`Taking off`**. **Step 3:** Therefore, **A** is correct. **Key Takeaway / Tip:** Because `Bird implements Flyable`, all methods of `Flyable` (including the unimplemented abstract method `takeOff()`) are part of `Bird`'s type signature. A: **Correct:** Option A (

) matches our derived result under Interfaces, Abstract Classes, and Concrete Subclasses. Because `Bird implements Flyable`, all methods of `Flyable` (including the unimplemented abstract method `takeOff()`) are part of `Bird`'s type signature. B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Interfaces, Abstract Classes, and Concrete Subclasses (correct choice: A). C: **Incorrect:** Option C (

) does not satisfy the conditions derived in the step-by-step analysis for Interfaces, Abstract Classes, and Concrete Subclasses (correct choice: A). D: **Incorrect:** Option D (

) does not satisfy the conditions derived in the step-by-step analysis for Interfaces, Abstract Classes, and Concrete Subclasses (correct choice: A).

**Answer: D** **Topic:** Object-Oriented Programming in Java — *Private Inner Classes Implementing a Public Interface* ### Step-by-Step Solution **Step 1:** In `class BankCustomer`, the inner classes `LoanApproved` and `LoanRejected` are `private`, but both implement the package-private interface `LoanEligibility` (which declares `void printLoanStatus()`), and `checkLoanEligibility()` returns a `LoanEligibility` reference: - If `salary > 50000`, `checkLoanEligibility()` returns `new LoanApproved()`. - Otherwise (`salary <= 50000`), it returns `new LoanRejected()`. **Step 2:** In `main()`, `bc1` has `salary = 45000` ($\le 50000$) and `bc2` has `salary = 60000` ($> 50000$): - Calling `bc1.checkLoanEligibility()` returns a `LoanRejected` object (typed as `LoanEligibility`), and chaining `.printLoanStatus()` prints **`Loan Rejected`**! **Step 3:** Therefore, **`bc1.checkLoanEligibility().printLoanStatus();`** (**D**) is correct. **Key Takeaway / Tip:** `BankCustomer` itself does not have a `printLoanStatus()` method (eliminating A and B); you must call `checkLoanEligibility()` first to obtain the `LoanEligibility` object. A: **Incorrect:** Option A (

) does not satisfy the conditions derived in the step-by-step analysis for Private Inner Classes Implementing a Public Interface (correct choice: D). B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Private Inner Classes Implementing a Public Interface (correct choice: D). C: **Incorrect:** Option C (

) does not satisfy the conditions derived in the step-by-step analysis for Private Inner Classes Implementing a Public Interface (correct choice: D). D: **Correct:** Option D (

) matches our derived result under Private Inner Classes Implementing a Public Interface. `BankCustomer` itself does not have a `printLoanStatus()` method (eliminating A and B); you must call `checkLoanEligibility()` first to obtain the `LoanEligibility` object.

**Answer: D** **Topic:** Object-Oriented Programming in Java — *Multiple Interface Implementation and Reference Type Restrictions* ### Step-by-Step Solution **Step 1:** In the given code, `class Document implements Readable, Writable`, where: - `interface Readable` declares **only** `void read();`. - `interface Writable` declares `default void write()`. **Step 2:** In `main()`, `Readable r1 = new Document();` declares `r1` with static type **`Readable`**: - `LINE 1` (`r1.read();`): Valid, because `read()` is declared in `Readable`. - `LINE 2` (`r1.write();`): **Compilation error!** Because `r1` is of type `Readable`, and `Readable` does not declare a `write()` method. **Step 3:** Therefore, **D** (`LINE 2 generates compiler error because r1 of type Readable cannot invoke method write()`) is correct. **Key Takeaway / Tip:** A reference variable of interface type `Readable` can only invoke methods declared in `Readable` (or `Object`), even if the underlying object also implements `Writable`. A: **Incorrect:** Option A (

) does not satisfy the conditions derived in the step-by-step analysis for Multiple Interface Implementation and Reference Type Restrictions (correct choice: D). B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Multiple Interface Implementation and Reference Type Restrictions (correct choice: D). C: **Incorrect:** Option C (

) does not satisfy the conditions derived in the step-by-step analysis for Multiple Interface Implementation and Reference Type Restrictions (correct choice: D). D: **Correct:** Option D (

) matches our derived result under Multiple Interface Implementation and Reference Type Restrictions. A reference variable of interface type `Readable` can only invoke methods declared in `Readable` (or `Object`), even if the underlying object also implements `Writable`.

**Answer: A** **Topic:** Object-Oriented Programming in Java — *Iterator Pattern and Downcasting from Object to Abstract Superclass* ### Step-by-Step Solution **Step 1:** Inspect the types and visibility in `ShapeList` and `IterTest`: - `iter.get_next()` has return type **`Object`** (declared in `interface Iterator`), so calling `iter.get_next().draw()` directly without casting (Option D) fails to compile. - `class Circle` is declared **`private`** inside `ShapeList`, so `Circle` is not visible inside `IterTest.main()` (Option B fails to compile). - `ShapeList` does not have a `draw()` method and `Circle` does not extend `ShapeList` (Option C fails). **Step 2:** However, `abstract class Shape` is package-private, declares `public abstract void draw()`, and `Circle extends Shape`! Therefore, downcasting the `Object` returned by `iter.get_next()` to `(Shape)` and calling `.draw()`: `((Shape)iter.get_next()).draw()` compiles cleanly and dynamically invokes `Circle.draw()` (**A**). **Key Takeaway / Tip:** Because `Circle` is a `private` inner class of `ShapeList`, external code in `IterTest` cannot reference `Circle` directly and must program against its visible superclass `Shape`! A: **Correct:** Option A (

) matches our derived result under Iterator Pattern and Downcasting from Object to Abstract Superclass. Because `Circle` is a `private` inner class of `ShapeList`, external code in `IterTest` cannot reference `Circle` directly and must program against its visible superclass `Shape`! B: **Incorrect:** Option B (

) does not satisfy the conditions derived in the step-by-step analysis for Iterator Pattern and Downcasting from Object to Abstract Superclass (correct choice: A). C: **Incorrect:** Option C (

) does not satisfy the conditions derived in the step-by-step analysis for Iterator Pattern and Downcasting from Object to Abstract Superclass (correct choice: A). D: **Incorrect:** Option D (

      **System Commands** **Section Id :** 64065369408 **Section Number :** 9 **Section type :** Online **Mandatory or Optional :** Mandator...) does not satisfy the conditions derived in the step-by-step analysis for Iterator Pattern and Downcasting from Object to Abstract Superclass (correct choice: A).