File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Method Overriding Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Method Overriding" Watch "Method Overriding" New topic
Author

Method Overriding

Prasanna Raman
Ranch Hand

Joined: Sep 05, 2010
Posts: 335
Hello All,
Why is that a sub class method that is overriding a base class method can't be more restrictive?

That is, why can't the access specifier be protected/private when the base class method is public?

Please explain with examples.

What is the primary reason behind disallowing this?


Thanks,
Prasanna
Marimuthu Madasamy
Ranch Hand

Joined: Jun 07, 2007
Posts: 72

A supertype reference can reference subclass objects. Through that reference, you can call all the public methods of supertype and you will be invoking the implementations of subclass if the methods are overridden by subclass.
With the above facts, if you are allowed to restrict the access of overridden methods, the compiler in no way can make sure that the overridden method will be invoked using supertype reference.

For example:


Here how can the compiler differentiate between case 1 that is broken and case 2 that is not? what if the process() method is in a library jar and you are not sure what are all the methods that will be invoked on the passed instance? In essence, it would break polymorphism.


- Marimuthu Madasamy
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40034
    
  28
Welcome to JavaRanch

Another way to put the above is that the overriding method is a refinement of the overridden method; that means that in every instance where the superclass method is feasible, the subclass method must be feasible too. If you try to change it from public to private, then it ceases to be feasible.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Or: a sub-type with more-restrictive access might no longer act like its super-type, violating the "is-a" rule.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40034
    
  28
The IS-A rule and the rule about "feasible whenever . . ." are probably closely related to each other.
Prasanna Raman
Ranch Hand

Joined: Sep 05, 2010
Posts: 335
Thanks for the replies.

I am close to getting it, but still have a few doubts. I am still not able to understand why a superclass type reference wouldn't be able to call the subclass method if it is less restrictive.

Can someone please explain with one more example?

Thanks a lot.


Thanks,
Prasanna
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Less restrictive? You said more previously. Subclass methods *can* be *less* restrictive.
Prasanna Raman
Ranch Hand

Joined: Sep 05, 2010
Posts: 335
Sorry, "more restrictive" was what I meant.

Sorry for the error.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

The issue is with *other* classes being able to call methods, although private means just that--private to the class; a superclass couldn't call it.

But that's not the point. If an ArrayList is-a List, what would it mean for an ArrayList that has a more restrictive List method? It would mean that ArrayList is-no-longer-a List, because something getting an ArrayList could no longer treat it as a list. Say our ArrayList had size() as a private. A method getting a List could no longer call size() on an ArrayList().
Prasanna Raman
Ranch Hand

Joined: Sep 05, 2010
Posts: 335
Thanks David.

Could you please show me an example of it?


Thanks,
Prasanna
Prasanna Raman
Ranch Hand

Joined: Sep 05, 2010
Posts: 335
" A method getting a List could no longer call size() on an ArrayList(). "

I don't really understand this point.


---
Prasanna
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

...
A Bar is-a Foo. A Baz is-not-a-Foo, because I can't call Foo methods on it, because plugh() was given private access. In Java, this is a compilation error, because if I extend a class, I must honor its contract. Foo's contract says there's a public plugh() method.
Prasanna Raman
Ranch Hand

Joined: Sep 05, 2010
Posts: 335
Could you elaborate the example to illustrate the "can't call Foo methods on it"?

Thanks,
Prasanna
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

This is a compilation error. (Well, it's two compilation errors, because I couldn't create Baz the way I did.)

theBaz is-not-a-foo because I can't call Foo methods on it. plugh() is defined as a public method of Foo(). In order for Baz to be a Foo I'd need to be able to call plugh(). I can't, because plugh() is private (or would be, if this more-restrictive definition was allowed, which it isn't, because it would break is-a relationships).

I don't know what else to tell you.
Prasanna Raman
Ranch Hand

Joined: Sep 05, 2010
Posts: 335
Thanks a lot David.

Sorry if I am being too naive.

"Baz theBaz = new Baz();
baz.plugh(); "


In the normal case, if the phugh in Baz is public, how would baz call the plugh in the superclass anyway?

If you do baz.plugh, would it not call the plugh in the Baz class?

How can it call the plugh in the base class?

I thought only a superclass reference can call a subclass method. But this is a subclass object calling a superclass method. Is that possible?


Thanks,
Prasanna
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Prasanna Raman wrote:In the normal case, if the phugh in Baz is public, how would baz call the plugh in the superclass anyway?

It wouldn't--that's the point of object-oriented programming: subclasses can provide their own behavior.

(Although it *can* call the superclass method by using super.plugh()).
I thought only a superclass reference can call a subclass method. But this is a subclass object calling a superclass method. Is that possible?

The subclass object isn't calling a superclass method. The code using the subclass is calling the plugh() method: where it's implemented is what gives OO programming its power. It could be implemented in Baz, it could be implemented in Foo. The calling code doesn't *care* where it's implemented.

And that's the point: if Baz made plugh() private, the is-a relationship is violated, and OO programming breaks.
Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4664
    
    5

Cross posted
http://forums.sun.com/thread.jspa?threadID=5449732

edit And http://www.java-forums.org/new-java/32291-overriding.html


luck, db
There are no new questions, but there may be new answers.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Please BeForthrightWhenCrossPostingToOtherSites; thanks! You've now gotten three sets of answers to the same question--and some of them were worded more concisely than mine. I certainly hope your confusion has been cleared up after all this effort from all these people.
Prasanna Raman
Ranch Hand

Joined: Sep 05, 2010
Posts: 335
Yes, Thanks David.

Sorry for the postings. I am new to the forums, so I posted multiple times!!

I will post a link to the other, incase I post somewhere else.

Sorry. Thanks for letting me know.


Thanks,
Prasanna
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Method Overriding