Given: interface Readable { public void readBook(); public void setBookMark(); } abstract class Book implements Readable { // line n1 public void readBook() { } // line n2 } class BBook extends Book…

Question

Options

• AReplace the code fragment at line_n1 with: class Book implements Readable {
• BAt line_n2 insert: public abstract void setBookMark();
• CReplace the code fragment at line_n3 with: abstract class BBook extends Book {
• DAt line_n4 insert: public void setBookMark() { }

• A
  7% (2)
• B
  10% (3)
• C
  3% (1)
• D
  80% (24)

Explanation

Option D is correct because BBook is a concrete class that inherits an unimplemented interface method (setBookMark()) from its abstract parent Book. A concrete class must provide implementations for all interface methods not fulfilled by its superclass - adding public void setBookMark() { } inside BBook satisfies that contract and allows compilation.

Option A is wrong: removing abstract from Book forces Book itself to implement setBookMark(), but it doesn't - so the error just moves up the hierarchy and Book fails to compile instead.

Option B is wrong: re-declaring setBookMark() as abstract inside Book is redundant (it's already implicitly abstract via the interface) and still leaves BBook - a concrete class - without an implementation, so the error remains.

Option C is wrong (as the intended answer): making BBook abstract merely defers the problem rather than solving it; any concrete subclass of BBook would still be forced to implement setBookMark(), and the intent of the code is to have a usable concrete class.

Memory tip: Think of the implementation chain as a relay race - the interface passes the baton, abstract classes can hold it temporarily, but the first concrete class in the hierarchy must cross the finish line by implementing every unresolved method.

No community discussion yet for this question.