Given: interface Doable { public void doSomething (String s); } Which two class definitions compile?

Question

Options

• Apublic abstract class Task implements Doable { public void doSomethingElse(String s) { } }
• Bpublic abstract class Work implements Doable { public abstract void doSomething(String s) { } public void doYourThing(Boolean b) { } }
• Cpublic class Job implements Doable { public void doSomething(Integer i) { } }
• DPublic class Action implements Doable { public void doSomething(Integer i) { } public String doThat(Integer j) { } }
• Epublic class Do implements Doable { public void doSomething(Integer i) { } public void doSomething(String s) { } public void doThat (String s) { } }

• A
  82% (18)
• B
  5% (1)
• C
  5% (1)
• D
  9% (2)

Explanation

A compiles because abstract classes are permitted to defer implementation of interface methods - Task doesn't provide doSomething(String s), but since it's abstract, that's legal; any concrete subclass must supply it instead. E compiles because it satisfies the interface contract by including doSomething(String s) with the exact required signature, and the extra overloaded and additional methods are perfectly valid.

B fails because abstract methods cannot have a body - abstract void doSomething(String s) { } must end with a semicolon, not curly braces. C fails because doSomething(Integer i) does not override doSomething(String s) - it's a different signature, so the interface method remains unimplemented in a concrete class, causing a compile error. D fails for a trivially tricky reason: Public (capital P) is not a valid Java modifier - keywords are case-sensitive. Memory tip: When a concrete class implements an interface, it must provide a method matching the exact parameter types - Integer and String are not the same, so doSomething(Integer) won't satisfy doSomething(String).

No community discussion yet for this question.