It's not a secret anymore!*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Sierra/Bates SCJP v6 - Interfaces and overridden methods Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Sierra/Bates SCJP v6 - Interfaces and overridden methods" Watch "Sierra/Bates SCJP v6 - Interfaces and overridden methods" New topic
Author

Sierra/Bates SCJP v6 - Interfaces and overridden methods

Scott Gordon Sutherland
Greenhorn

Joined: Apr 18, 2011
Posts: 9
Hi


My query is drawn from Question 46 of the 2nd mock exam on the CD. The answer notes that to allow compilation that the method on line 4 of Lame.java must be declared public. (full details below for reference)

As this is an override why can you not implement a concrete method with a lesser or equal level of access.
1. Assuming the interface is public (i.e. in fulfillment of Answer A) the method could be public, protected, default or private. As it is already default, making accessible to the Lamentable class, any subclass or any other class in the same package. Why must it also be made public - it is not clear from the question that this method need be accessible more widely than its within its class.

2. Then on a more general note - what if I dont want the Lame version of lament to be more accesible than default allows? For example if any other classes which implement Lamentable have their own lament methods. Is there perhaps an underlying reason that this may create later code problems?


Question 46
Given two files:





In order to compile these two files (which are both located in appropriate directories for their
packages), what changes are necessary?

Correct Answer
A: On line 3 of Lamentable.java, this interface must be declared public.
D: Method on line 4 of Lame.java must be declared public.
G: Lines 12-14 in Lame.java must be deleted.
H: Lines 16-18 in Lame.java must be deleted.

Regards
Scott
Boris Mechkov
Ranch Hand

Joined: May 13, 2011
Posts: 72

Scott Gordon Sutherland wrote:Hi


My query is drawn from Question 46 of the 2nd mock exam on the CD. The answer notes that to allow compilation that the method on line 4 of Lame.java must be declared public. (full details below for reference)

As this is an override why can you not implement a concrete method with a lesser or equal level of access.
1. Assuming the interface is public (i.e. in fulfillment of Answer A) the method could be public, protected, default or private. As it is already default, making accessible to the Lamentable class, any subclass or any other class in the same package. Why must it also be made public - it is not clear from the question that this method need be accessible more widely than its within its class.

2. Then on a more general note - what if I dont want the Lame version of lament to be more accesible than default allows? For example if any other classes which implement Lamentable have their own lament methods. Is there perhaps an underlying reason that this may create later code problems?


Question 46
Given two files:





In order to compile these two files (which are both located in appropriate directories for their
packages), what changes are necessary?

Correct Answer
A: On line 3 of Lamentable.java, this interface must be declared public.
D: Method on line 4 of Lame.java must be declared public.
G: Lines 12-14 in Lame.java must be deleted.
H: Lines 16-18 in Lame.java must be deleted.

Regards
Scott


Hi!
Remember the overriding method can be LESS restrictive than the original method, but canNOT be more restrictive. The void lament() method in the interface is PUBLIC ABSTRACT by default regardless of what is listed (in our case public and abstract have been omitted).
So a concrete method can be ONLY PUBLIC, because default, private or protected are MORE restrictive than the public method in the interface.
Boris Mechkov
Ranch Hand

Joined: May 13, 2011
Posts: 72

Also on your point 2:
If you wanted a LAMENT method that is more restrictive than what the interface allows, just overload the method and do some in-method coding to make it work similarly to the overridden method. This might be a solution.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4343
    
    8

This is all about the Liskov Substitution Principle. This states that any place where an instance of a particular class is used, you should be able to substitute an instance of any subclass for it. Allowing a method to be overridden with greater restrictions breaks this principle. For example:

That code should be valid. On line 2, the compiler sees the reference type is Lamentable, and knows that it has a public lament method. But the object is actually a Lame, and that doesn't. If we allow the class to be defined with more restrictive accessibility, then we've broken compile-time protection against using invalid methods.

Making methods more accessible when you override (which doesn't apply here, because all interface methods are implicitly public) doesn't break this principle, and is allowed. An example is Object.clone() - it's protected, but when making an object cloneable you're expected to override it and make it public.
Scott Gordon Sutherland
Greenhorn

Joined: Apr 18, 2011
Posts: 9
Hi Matthew

Thanks - this is the type of information I am looking for.
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Can I just remark that Lamentable is my favorite interface example I've ever seen?
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Sierra/Bates SCJP v6 - Interfaces and overridden methods
 
Similar Threads
help with blank final variables
Unreachable code?
java
Question regarding javacertificate.com study question
Boolean Question