Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Doubt in overriding

 
Padma priya Gururajan
Ranch Hand
Posts: 437
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Pie
Posts: 15436
41
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why don't you just try it out and see what happens when you try to compile your code?
 
Mansukhdeep Thind
Ranch Hand
Posts: 1158
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Alvaro Vargas
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Padma,

As Mansukhdeep says, you can´t make overriden methods access modifiers more restrictive than the overriden one. That´s for sure.
 
Winston Gutkowski
Bartender
Pie
Posts: 10492
64
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Mansukhdeep Thind
Ranch Hand
Posts: 1158
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 10492
64
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1158
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 10492
64
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Pie
    Posts: 49733
    69
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    As faro final: remember that every opportunity to change something in an object is an opportunity for something to go wrong.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic