OOP and private field inheritance

Question

In C #, the specification says:

Instance constructors, destructors, and static constructors are not inherited, but all other members, regardless of their declared accessibility (§3.5). However, depending on the declared availability, inherited members may not be available in the derived class.

therefore, private fields are inherited into the derived class, but they are not available.

However, the Java specification says:

Only class members declared protected or publicly inherited by subclasses declared in a package other than the class declared.

therefore, private fields are not inherited into the derived class.

And what does OOP theory explain? Are C # or Java Developers Right?

This aspect is a little confusing.

PS I have no experience in C ++? What do C ++ developers say?

Answer 1

Well, the C # version is more understandable, because even in Java private fields will be available as part of the child, but they will not be available directly unless you have an open getter in the parent class to get its value.

In fact, you can use the mapping to make private fields (of the parent) available and read their values ​​directly.

Answer 2

Keeping things simple and clean, taking the portion of the quote you mentioned for C ++

However, depending on their declared accessibility, inherited members may not be available in the derived class.

The same thing happens in Java. You also cannot access private fields in Java.

There are methods around them for accessing another story (encapsulation)

Answer 3

Answers at least the C # / Java part, as I don't know very well in C ++.

However, depending on their declared accessibility, inherited members may not be available in the derived class.

The C # spec seems a bit more meaningful, although Java handles private mailboxes the same way. Private members of the base class also exist in Java (however, they are not inherited; see, are private fields inherited in Java? ). Since you cannot access them, it is still not useful. Of course, internal elements are initialized by setting private members. So the instances of your derived class, of course, have all the private members of the base class, inheritance, however, means any kind of polymorphism, which implies that you can override (if your member is not static or final/selead ), has nothing to do to private members.

Thus, in pursuit, there should be no need to access the internal elements at all, neither in C #, nor in Java, or anywhere else. Just suppose your derived instances fully initialize all the underlying elements and do your actual work.

Regarding what you call the “OOP theory,” I doubt that there is a cleaner answer than for this principle (which is implemented differently in these languages). Private members have nothing to do at all, OOP just processes interactions between objects, surrounding them not with their actual internal elements.

Answer 4

I think the confusion is related to the confusing wording. In Java or C # or any other OO language, if you create a child, you must call the parent constructor because the parent is part of the child. Very often, a call to the parent constructor is done implicitly.

Thus, the private attributes of the parent are always present somewhere inside the child. Then OOP ensures that you cannot access the private attributes in the child. This encapsulation is an important point. And this fact is described by two links: either you call it attributes are not inherited, or you say that they are inherited, but not visible.

As mentioned above, you can (ab) use the reflection library to get around these limitations.