Q on Classes & SubClasses with protected members
 

Hi..All,

Can someone please explain me this

"Access to protected members of the superclass would also be permitted
via any references of subclasses. The above restriction helps to ensure
that subclasses in package different from their superclass can only
access protected members of the superclass in their part of the
inheritance hierarchy".

Why is this restriction for class in a different package extending a
class from a different package?

This is from Khalid A Mughal's book.



Regards,

P

Re: Q on Classes & SubClasses with protected members
 

"Praveen" <nospam@spam.com> wrote in message
news:W0Yub.9088$J31.4588@newssvr13.news.prodigy.co m...
> Hi..All,
>
> Can someone please explain me this
>
> "Access to protected members of the superclass would also be permitted
> via any references of subclasses. The above restriction helps to ensure
> that subclasses in package different from their superclass can only
> access protected members of the superclass in their part of the
> inheritance hierarchy".
>
> Why is this restriction for class in a different package extending a
> class from a different package?
>
> This is from Khalid A Mughal's book.
>
>
>
> Regards,
>
> P
>

If I understand correctly, the paragraph refers to "package private"
members -- members, declared with no access specifier, that appear public to
other members of the declaring class's package, but private to members from
external packages. This allows for some degree of coupling due to
implementation, but prevents implementation details from "leaking out" via
subclassing. It is common when implementing a component for example, that it
comprises multiple classes that must collaborate while presenting a unified
interface. The use of package private members allows the collaborating
classes to communicate with each other as necessary, but prevents clients
from writing code that depends on those members. Clients should program to
the component's interface only.

The stipulation about subclasses prevents using extension to circumvent the
encapsulation: say a component C is implemented as a collaboration of
classes A and B. In some cases, I could get access to implementation details
by writing my own subclass of A and installing it in C. For a concrete
example, imagine C being a logon dialog. In principle, I could subclass one
or more of the classes used by the dialog, creating a new version that
transmits to me the user's id and password.

That example might be a bit contrived, but there are many examples in Swing
of using package private access among classes that make up the components.

HTH!
Sean.