This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes Doubt in overriding Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Doubt in overriding" Watch "Doubt in overriding" New topic
Author

Doubt in overriding

Padma priya Gururajan
Ranch Hand

Joined: Oct 05, 2006
Posts: 430
Hello,

In Overridden methods, is it possible to have public access modifier in the super class and protected modifier in the subclass for the method that is overridden?


Padma priya N.G.
Be the change you want to be - Mahatma Gandhi
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 13884
    
  10

Why don't you just try it out and see what happens when you try to compile your code?


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

No Padma. You cannot narrow down the access level of a method present in the super class while overriding it in the sub class. The overriding method may have a less restrictive access modifier.


~ Mansukh
Alvaro Vargas
Greenhorn

Joined: Aug 04, 2009
Posts: 1
Hi Padma,

As Mansukhdeep says, you can´t make overriden methods access modifiers more restrictive than the overriden one. That´s for sure.


Ing. Alvaro Vargas
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7081
    
  16

Mansukhdeep Thind wrote:No Padma. You cannot narrow down the access level of a method present in the super class while overriding it in the sub class. The overriding method may have a less restrictive access modifier.

Since you like to speculate on these things Mansukhdeep, why do you think that's so?

Personally, I've always thought that Java could do with a 'fixed' keyword (eg, fixed protected) that prevents subclasses from widening the access qualifier; but I suspect it's far too late now.

It's one decision that I think the Java Gods got wrong.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Artlicles by Winston can be found here
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Since you like to speculate on these things Mansukhdeep, why do you think that's so?


Well Winston, I would consider it safe to say that code re-use is one thing I would keep in mind when I design my application. Extending a class and then marking the sub class overriding method with more restrictive access modifier will go against the very core OOP concepts of polymorphism and code re-use.

Personally, I've always thought that Java could do with a 'fixed' keyword (eg, fixed protected) that prevents subclasses from widening the access qualifier; but I suspect it's far too late now.


You could always voice your opinion to James, Joshua etc. Who knows?
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7081
    
  16

Mansukhdeep Thind wrote:I would consider it safe to say that code re-use is one thing I would keep in mind when I design my application. Extending a class and then marking the sub class overriding method with more restrictive access modifier will go against the very core OOP concepts of polymorphism and code re-use.

But I wasn't arguing that one should be able to restrict visibility; what I was saying is that it would sometimes be useful to prevent it from being widened. Basically, what the current set-up says is: "I know I made this method protected, but in fact it's actually public, because I can't stop you from making it so."

Which means that you end up with anomalies like AbstractList.removeRange() and LinkedHashMap.removeEldestEntry(), which were never intended to be made public, but can be exposed by stupid (or unscrupulous) developers.

It's not a major issue, but it can be a bit of a nuisance sometimes.

Winston
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Well sir, you have a total of 35 years IT experience. And my total age is 28. Give me some room for making mistakes. Sooner or later, I will get there. That's a promise. Until then you can consider me one of those "stupid and unscrupulous" developers who is learning at the expense of the customer.

Which means that you end up with anomalies like AbstractList.removeRange() and LinkedHashMap.removeEldestEntry(), which were never intended to be made public, but can be exposed by stupid (or unscrupulous) developers.


Why do you say so? What is the danger if I override a method and widen its access in the sub-class?
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7081
    
  16

Mansukhdeep Thind wrote:Why do you say so? What is the danger if I override a method and widen its access in the sub-class?

Probably not a lot - if the original method was written properly (and I have no reason to think it wasn't) - but before you do so, you should ask yourself this: why did the original designer make it protected?

The fact is that I'm an alumnus of the Paranoid School of Programming, and our motto is akin to Murphy's Law: "if a subclass can be screwed up, it will be".

So keywords like private and final are our stock-in-trade:
  • Never define a non-final class unless you know it's going to be extended.
  • Never define a non-private member unless you know it will be needed. And don't define non-private variables at all.
  • Assume that anything that isn't private is actually public.
  • Copy all arrays: input or output.
  • Don't implement Serializable unless you have a large supply of Mogadon available.
  • Setters are for suckers.

  • Just a few of the school aphorisms...

    Winston
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 36599
        
      16
    As faro final: remember that every opportunity to change something in an object is an opportunity for something to go wrong.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Doubt in overriding
     
    Similar Threads
    instance varibles and static methods????
    Restrictive Access modifier????
    Cannot create a concrete sub-class of a public abstract class, in another package
    Questions
    Why can the final modifier be used with static methods?