5

In C# the spec says:

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

so private fields are inherited into a derived class but they are not accessible.

However the Java spec says:

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.

so private fields are not inherited into a derived class.

And what does explain the OOP theory? Is correct C# or Java designers?

A bit confused on this aspect.

P.S. I haven't C++ experience? What does C++ designers says on this?

xdevel2000
  • 20,780
  • 41
  • 129
  • 196
  • 2
    There isn't THE OOP theory. OOP is a general concept/programming style which might be supported by different languages in different ways. You can even do OOP in plain C. – MikeMB Feb 16 '16 at 09:17

4 Answers4

4

Well, the C# version is more-clear because even in Java, private fields will be available as part of the child object but they will no be directly accessible unless you have a public getter in the parent class to get its value.

You can actually use reflection to make private fields (of the parent ) accessible and read their values directly.

TheLostMind
  • 35,966
  • 12
  • 68
  • 104
  • How you can prove that also in Java private fields are inherited? I think the spec is the official document and it says don't! – xdevel2000 Feb 16 '16 at 09:27
  • @xdevel2000 - What if you have public getter for private field in the parent?.. What will that method return in the child?. If that value didn't even exist, then what would be the point of actually allowing public methods to be inherited? – TheLostMind Feb 16 '16 at 09:33
  • the point is not having a public field. The point is if a derived class inherit private member but it is not however accessible. – xdevel2000 Feb 16 '16 at 09:35
  • @xdevel2000 you can use reflection to inspect your class and see that those fields are still there. – Revolver_Ocelot Feb 16 '16 at 09:36
  • @xdevel2000 - Yes, thats the point. The derived class has data (private fields) which it cannot access. – TheLostMind Feb 16 '16 at 09:37
3

Keeping the things simple and clean, taking some part of quote you mentioned for c++

However, depending on their declared accessibility, inherited members might not be accessible in a derived class.

The same thing happens in Java as well. You can't access private fields in Java too.

There are methods around them to access which is another story (encapsulation)

Suresh Atta
  • 120,458
  • 37
  • 198
  • 307
1

Answering at least the C#/Java-part as I don´t know much on C++.

However, depending on their declared accessibility, inherited members might not be accessible in a derived class.

The C#-spec seems to be a bit more meaningful, although Java handles private mebers the same way. The private members from base-class also exist in Java (however they are not inherited, see are private fields inherited in Java?). As you cannot access them this is not usefull anyway. The internals however are of course initialized by setting the private members also. So 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 you might be able to override (assuming your member is not static or final/selead) them which makes no sense at private members.

So coming to the chase there should be no need for accessing the internals at all, neither in C# nor in Java nor anywhere else. Simply assume your derived instances get all the base-members fully-initialized and do your actual work.

Relating to what you call "OOP-theory" I doubt there is a cleaner answer as for this principle (which is implemented in different ways in the mentioned languages)private members have no relevance at all. OOP merely handles the interactions between objects with their surrounding not their actual internals.

Community
  • 1
  • 1
MakePeaceGreatAgain
  • 35,491
  • 6
  • 60
  • 111
1

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

So the private attributes from the parent are always present somewhere within the child object. Then OOP ensures, that you can not access the private attributes within the child. This encapsulation is the important point. And this fact is described by the two references: Either you call it the 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 restriction.

Frank Essenberger
  • 335
  • 1
  • 7