Private Members Not Inherited!

[ghd]

Beginners beware!

Usually in lessons on inheritance, we learn that when a class extends another, the former inherits all the members of the latter. This statement is only partly true (in fact it is misleading!). The complete truth is that private members are not inherited.

I wish to restate the principle: "The access modifier 'private' is not just an access modifier. It also means that the member who has this modifier will not be inherited."

[r035198x]

Beginners beware!

Usually in lessons on inheritance, we learn that when a class extends another, the former inherits all the members of the latter. This statement is only partly true (in fact it is misleading!). The complete truth is that private members are not inherited.

I wish to restate the principle: "The access modifier 'private' is not just an access modifier. It also means that the member who has this modifier will not be inherited."

That's why you should be particular about the books/tutorials you read. A general rule of thumb is to try the horse's mouth first.

[ghd]

That's why you should be particular about the books/tutorials you read. A general rule of thumb is to try the horse's mouth first.

Hey! wait a minute. I did look up the reference you mentioned. I think private members are inherited after all! I am quoting from The Java Tutorials:
A subclass does not inherit the private members of its parent class. However, if the superclass has public or protected methods for accessing its private fields, these can also be used by the subclass.

If the derived class can access the private member of its parent through an inherited public method does it not imply that the derived class does indeed also have the private member as its own? I wrote a simple java program to illustrate this principle. See below (-:

class Animal {
	private String name;

	String getName() {
		return name;
	}

	void setName(String n) {
		name = n;
	}	
}

class Cat extends Animal {
	public static void main(String[] args) {
		Cat aCat = new Cat();
		aCat.setName("Catalina");
		System.out.println("Hi cat! " + aCat.getName());
	}
}

The result of running this is...
Hi cat! Catalina

If the private member 'name' of the class 'Animal' is not a member of the class 'Cat' then where is the string 'Catalina' getting stored? Hence it makes sense to conclude that 'name' is also a member of 'Cat', although it cannot be accessed using the '.' notation.

What do you think?

[JosAH]

If the private member 'name' of the class 'Animal' is not a member of the class 'Cat' then where is the string 'Catalina' getting stored? Hence it makes sense to conclude that 'name' is also a member of 'Cat', although it cannot be accessed using the '.' notation.

What do you think?

Yep that's correct. It isn't much though: what would be the reason for having a
private member that gets exposed to the world through public accessors and
mutators? (getters and setters).

The reason is hiding the implementation details of the class. As a 'side effect'
a subclass can access the private member of the super class just as the entire
world can do.

kind regards,

Jos

[ghd]

Yep that's correct. It isn't much though: what would be the reason for having a
private member that gets exposed to the world through public accessors and
mutators? (getters and setters).

So can we restate the principle: Private members are inherited but cannot be accessed in the subclass using the "." notation.

kind regards,
ghd

[JosAH]

So can we restate the principle: Private members are inherited but cannot be accessed in the subclass using the "." notation.

kind regards,
ghd

Yup you can think of it that way; I prefer to think of those private members as
space taken up in the subclass objects that can not be reached in the subclass
objects without things discussed in this thread before (at least protected getters
and/or setters).

This raises the question: should a class meant to be subclassed have private
data members? I'd say yes but I'm open for discussion about this.

kind regards,

Jos

[krishnabhargav]

Private members are not inherited.

Being able to access private members through accessor methods like getters and setters do not mean they are inherited but cannot be accessed with a "." operator.

Inheritance has to do with the visibility of the members. Take this case, if you have a private method say doSomething(), you cannot invoke it from subclass. If it was inherited there should be a way to invoke it, right? It does not make sense to write a new method in the super class like

public void pleaseDoSomethi ng()
{
doSomething();
}

Remember there is a reason for having "protected","pr ivate" and "public" modifiers.

[ghd]

This raises the question: should a class meant to be subclassed have private
data members? I'd say yes but I'm open for discussion about this.

kind regards,

Jos

I find one good reason for having private members in a class irrespective of whether it can be subclassed or not. The reason is that the author of the class may not want other classes (including the subclasses) to get or set the member by mere assignment operator. In other words, the author may want to run some code whenever the member is got or set.

Another reason could be, as JosAH has pointed out - encapsulation - confirming to certain conventions like the ones we follow when designing a java bean. In this case the introspection process looks for methods that begin with 'set' and 'get'. Please correct me if i am wrong.

Inheritance has to do with the visibility of the members. Take this case, if you have a private method say doSomething(), you cannot invoke it from subclass. If it was inherited there should be a way to invoke it, right?

The fact is that a class indeed has (owns) the private members of its parent. You can see for yourself by trying out the code that i showed before in this thread. Now, whether you call such behaviour as 'inheritance' or otherwise left for leaders of the Java community to decide.

kind regards,

ghd

[krishnabhargav]

I find one good reason for having private members in a class irrespective of whether it can be subclassed or not. The reason is that the author of the class may not want other classes (including the subclasses) to get or set the member by mere assignment operator. In other words, the author may want to run some code whenever the member is got or set.

Another reason could be, as JosAH has pointed out - encapsulation - confirming to certain conventions like the ones we follow when designing a java bean. In this case the introspection process looks for methods that begin with 'set' and 'get'. Please correct me if i am wrong.



The fact is that a class indeed has (owns) the private members of its parent. You can see for yourself by trying out the code that i showed before in this thread. Now, whether you call such behaviour as 'inheritance' or otherwise left for leaders of the Java community to decide.

kind regards,

ghd

so I inherit a JFrame, so I own the private members? Also Java community leaders do not decide what inheritence is. It has been around right since the 60's (thats when Gosling was probably in primary school at that time).

Try this out.

class Super
{
    private Super()
    {
        
    }
}
class Sub extends Super
{
    
}

It is an error...

[BigDaddyLH]

Alright, all this hullabaloo about private+inherit s made me crack open my link to the JLS, to the chapter on classes: http://java.sun.com/docs/books/jls/t...s.html#8.2.1.3

Here are some relevant quotes on private+inherit s (and a few on constructors):

Members of a class that are declared private are not inherited by subclasses of that class. Only members of a class that are declared protected or public are inherited by subclasses declared in a package other than the one in which the class is declared.

Constructors, static initializers, and instance initializers are not members and therefore are not inherited.

A class inherits from its direct superclass and direct superinterfaces all the non-private fields of the superclass and superinterfaces that are both accessible to code in the class and not hidden by a declaration in the class.

Note that a private field of a superclass might be accessible to a subclass (for example, if both classes are members of the same class). Nevertheless, a private field is never inherited by a subclass.

It is a compile-time error for a private method to be declared abstract. It would be impossible for a subclass to implement a private abstract method, because private methods are not inherited by subclasses; therefore such a method could never be used.

Constructor declarations are not members. They are never inherited and therefore are not subject to hiding or overriding.