Doubt in overriding

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?

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

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.

Hi Padma,

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

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

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?

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

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?

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

As faro final: remember that every opportunity to change something in an object is an opportunity for something to go wrong.