Java superclass restriction design

A

Arvind

hi,

In Java if a superclass has a particular access specifier for a
method it is allowable by the subclass to broaden the access, but NOT
restrict it.

eg: class A
{
protected void print(){ }
}

class B extends A
{
private void print(){ } /* NOT ALLOWED! (It will be alowed if
it was protected or public) */
}

This is exactly the opposite of what is applicable in C++. Coming
from C++ , i find this strange, as this broadening rule, would expose
methods that a 'library' writer would not have wanted to expose. That
means clients could potentially write malicious code using this
concept, whereas in C++ one can prevent the clients from having access
to it and control to such methods can be controlled by a subclass.

Could someone please explain to me the reason behind such a design.
There must be something that iam missing. Please point it out.

Thanks
Arvind.
 
P

Paul H. van Rossem

hi,

In Java if a superclass has a particular access specifier for a
method it is allowable by the subclass to broaden the access, but NOT
restrict it.

eg: class A
{
protected void print(){ }
}

class B extends A
{
private void print(){ } /* NOT ALLOWED! (It will be alowed if
it was protected or public) */
}

This is exactly the opposite of what is applicable in C++. Coming
from C++ , i find this strange, as this broadening rule, would expose
methods that a 'library' writer would not have wanted to expose. That
means clients could potentially write malicious code using this
concept, whereas in C++ one can prevent the clients from having access
to it and control to such methods can be controlled by a subclass.

Could someone please explain to me the reason behind such a design.
There must be something that iam missing. Please point it out.

Thanks
Arvind.

In short:
1) Subclasses /extend/ the baseclass, so they always have /more/
functionality.
So you should not and cannot be allowed to hide methods of the
superclass by restricting the visibility.
2) If you want to prevent a subclass to override a method, you can
declare that method *final* (or even the whole class, like what's
done for the String class).

Paul.
 
O

Oscar kind

Arvind said:
In Java if a superclass has a particular access specifier for a
method it is allowable by the subclass to broaden the access, but NOT
restrict it.

eg: class A
{
protected void print(){ }
}

class B extends A
{
private void print(){ } /* NOT ALLOWED! (It will be alowed if
it was protected or public) */
}

If restricting access is possible, this is not possible:

A objectA = new B();
a.print();


In other words: you break polymorphism, one of the fundamentals of OO.
 
E

Eric Sosman

Arvind said:
hi,

In Java if a superclass has a particular access specifier for a
method it is allowable by the subclass to broaden the access, but NOT
restrict it.

eg: class A
{
protected void print(){ }
}

class B extends A
{
private void print(){ } /* NOT ALLOWED! (It will be alowed if
it was protected or public) */
}

This is exactly the opposite of what is applicable in C++. Coming
from C++ , i find this strange, as this broadening rule, would expose
methods that a 'library' writer would not have wanted to expose. That
means clients could potentially write malicious code using this
concept, whereas in C++ one can prevent the clients from having access
to it and control to such methods can be controlled by a subclass.

Could someone please explain to me the reason behind such a design.
There must be something that iam missing. Please point it out.

Each B object "is an" A object, so some piece of
code that works with an A must also be able to work
with a B. For example, consider:

A obj = new B();
obj.print();

This should invoke B's print() method, not A's, because
of the way overriding works. But if B's print() were
private, this code could only work if it were actually
inside the B class: an ordinary third-party A consumer
could not perform the call. Since a B "is an" A, that
would amount to having a special kind of A that violates
the basic contract of A objects.

I think that explains why "narrowing" the access
is forbidden. The other side of your question asks why
"widening" the access is allowed. To that, all I can say
is that if the B designer wants to grant wider access to
methods and fields, that's the B designer's business.
Note that making B's print() method public doesn't widen
the access to A's print(); it remains whatever the A
designer chose. There is no way for code that lacks
access to A's print() to somehow get at it by means of
a B object, so I think your "malicious code" fears are
unfounded.

Of course, if B has access to A's methods and calls
them, a third party in possession of a B object can use
it to make indirect calls to A's methods. But it can do
so only to the extent A's designer chose to allow; if A
has methods and fields that should not be accessible even
to subclasses and package partners, the A designer can
choose to make them private.
 
C

Chris Smith

Arvind said:
This is exactly the opposite of what is applicable in C++. Coming
from C++ , i find this strange, as this broadening rule, would expose
methods that a 'library' writer would not have wanted to expose. That
means clients could potentially write malicious code using this
concept, whereas in C++ one can prevent the clients from having access
to it and control to such methods can be controlled by a subclass.

I'm not entirely sure where you think the security attack may come from,
but I can tell you that there's no security issue here.

If a malicious entity writes a subclass. We'll assume a mobile code or
plugin environment where this is possible, and that the subclass is in a
different package. Any code that you can override can also be called.
So anything that you might be worried about illicitly "exposing" by
broadening access specifiers via inheritance is already exposed to be
called from within the subclass anyway. There is not loosening of any
security requirements on calling code here.

Remember that it's not possible to override an inaccessible member, such
as a private or package-access member. Therefore, anything that's
inaccessible will remain inaccessible.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top