Question about inheritance of private variables

L

lcan

Good evening!

Most books say private members are not inherited. This cannot be always true
as a private instance variable in the superclass can be accessed in the
subclass using public accessor methods define in the superclass. In effect
the private data is inherited by the subclass but not accessible in the
subclass. Can someone help confirm this?

Best regards,
lc
 
B

Brian Kildea

lcan said:
Good evening!

Most books say private members are not inherited. This cannot be always true
as a private instance variable in the superclass can be accessed in the
subclass using public accessor methods define in the superclass. In effect
the private data is inherited by the subclass but not accessible in the
subclass. Can someone help confirm this?

Best regards,
lc

I'm sure that people would argue both points of view based on the
application of subtle semantics nuances to the terms inheritance,
superclass, etc. However, what you said is correct: If you construct an
instance of a subclass, part of the construction process will create the
private variable defined by the base class. As long as the base class also
defines non-private accessor methods (protected, package or public) the base
class can effectively have access to the private variable.

-Brian
 
B

Brian Kildea

Brian Kildea said:
I'm sure that people would argue both points of view based on the
application of subtle semantics nuances to the terms inheritance,
superclass, etc. However, what you said is correct: If you construct an
instance of a subclass, part of the construction process will create the
private variable defined by the base class. As long as the base class also
defines non-private accessor methods (protected, package or public) the base
class can effectively have access to the private variable.

-Brian

excuse me... the sub-class can effectively have access to the private
variable.
 
T

Tony Morris

This argument has been had many times (and I recall one such debate with
Neal Gafter who is the author of the Sun Java compiler).

The solution is to define "inherited".
According to the Java Language Specification, the definition of "inherited"
is such that the data member is available by subclasses. Using this
definition, private members are not inherited, HOWEVER, they are 'there',
that is, instances of the subclass contains the data that is held by the
private member - it is just not exposed by the superclass.

There is an excellent example that demonstrates this point.
What is the output of the following and why (You'll need the JLS, a cup of
coffee and a clear mind) ?

// Enjoy
class T
{
private final String name;

private void prname()
{
System.out.println(name);
}

T(String name)
{
this.name = name;
}

public static void main(String[] args)
{
new T("main").doit();
}

private void doit()
{
new T("doit")
{
void method()
{
prname();
}
}.method();
}
}

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)
 
A

Adam

// Enjoy
class T
{
private final String name;

private void prname()
{
System.out.println(name);
}

T(String name)
{
this.name = name;
}

public static void main(String[] args)
{
new T("main").doit();
}

private void doit()
{
new T("doit")
{
void method()
{
prname();
}
}.method();
}
}

'doit' will appear on the console, right?
 
D

Dario

Adam said:
class T
{
private final String name;

private void prname()
{
System.out.println(name);
}

T(String name)
{
this.name = name;
}

public static void main(String[] args)
{
new T("main").doit();
}

private void doit()
{
new T("doit")
{
void method()
{
prname();
}
}.method();
}
}

'doit' will appear on the console, right?

No! Please retry...

- Dario
 
D

Dario

Adam said:
// Enjoy
class T
{
private final String name;

private void prname()
{
System.out.println(name);
}

T(String name)
{
this.name = name;
}

public static void main(String[] args)
{
new T("main").doit();
}

private void doit()
{
new T("doit")
{
void method()
{
prname();
}
}.method();
}
}


'doit' will appear on the console, right?

No. Please retry.

It would print 'doit' if prname is public,
but prname is private so it will print 'main'.

This example is excellent!
I was able to solve it just because my mind is clear at 9:45 AM.
Probably at 9:45 PM I will not able to solve it!

- Dario
 
A

Adam

No. Please retry.

It would print 'doit' if prname is public,
but prname is private so it will print 'main'.

Wow! Indeed!
Compiler binds prname() in method() in anonymous class
with T.prname() (of outer (enclosing) class), not with
T.$1.prname() !!!

Of course, anonymous class inherits from T, so has no access
to private prname() of the base class!
On the other hand this anonymous class is an inner class,
so has access to private prname of the outer class,
and the name of the object of outer class is 'main',
not 'doit' !

My confusion was caused by the fact that I didn't
pay attention to the inheritance.

BTW, prname() does not have to be public to see 'doit'
as a result. It would be enough if it was protected,
then the inheriting anonymous class would have access to it.

Good one!

Adam
 
L

lcan

Thanks Tony. I think in OO terms the attribute is inherited but just not
directly acessible. I am incline to disagree with the Java definition of
inheirtance. Are there
good reasons behind?

BTW: Your example is excellent!

Cheers,
-lc
Tony Morris said:
This argument has been had many times (and I recall one such debate with
Neal Gafter who is the author of the Sun Java compiler).

The solution is to define "inherited".
According to the Java Language Specification, the definition of "inherited"
is such that the data member is available by subclasses. Using this
definition, private members are not inherited, HOWEVER, they are 'there',
that is, instances of the subclass contains the data that is held by the
private member - it is just not exposed by the superclass.

There is an excellent example that demonstrates this point.
What is the output of the following and why (You'll need the JLS, a cup of
coffee and a clear mind) ?

// Enjoy
class T
{
private final String name;

private void prname()
{
System.out.println(name);
}

T(String name)
{
this.name = name;
}

public static void main(String[] args)
{
new T("main").doit();
}

private void doit()
{
new T("doit")
{
void method()
{
prname();
}
}.method();
}
}

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)


lcan said:
Good evening!

Most books say private members are not inherited. This cannot be always true
as a private instance variable in the superclass can be accessed in the
subclass using public accessor methods define in the superclass. In effect
the private data is inherited by the subclass but not accessible in the
subclass. Can someone help confirm this?

Best regards,
lc
 

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

No members online now.

Forum statistics

Threads
474,434
Messages
2,571,685
Members
48,796
Latest member
Greg L.

Latest Threads

Top