R
relient
Question: Why can't you access a private inherited field from a base
class in a derived class? I have a *theory* of how this works, of
which, I'm not completely sure of but makes logical sense to me. So,
I'm here for an answer (more of a confirmation), hopefully.
First let me say that I know people keep saying; it doesn't work
because the member "is a private". I believe there's more to it than
just simply that...
Theory: You inherit, not only the members in the base class, but the
whole base class itself - as an object, which contains the members.
Therefore, this has *almost* the same effect as if you declared a base
class manually in the derived class as shown in figure 1:
public class Base
{
private string name;
// more members and methods...
}
public class Derived
{
// instance members:
Base baseField;
private uint numbersField;
}
and if you tried to access the private member "name" of baseField
inside a method in the derived class like: baseField.string, you would
get an error, because it is private and can only be accessed within
it's own class scope (container). And similarly, this holds true for
why you cannot access a private base member in a derived class in a
"base and derived class relationship". This theory makes good, perfect
logical sense (to me) of why you *cannot* access a private member
*because* you're trying to access a private member outside of the
container where it is defined. And also, the keyword "base" then
essentially becomes the reference to that base class object. Just like
"this" is a reference to an instantiated object. And this(not the
keyword), also, essentially means this: when you derived a class from a
base class, you then have "two" classes within one unit, and this unit
is the drived class.
To elaborate some more, let's throw in a problematic problem:
So with that just said, How then does the keywords "base" and "this"
refer to the same "data" (fields etc..) and "code" (methods etc..) - at
times - when they *are* two different objects which are within one unit
- the derived class (this == drived class object AND base == base class
object)? But, they also, sometimes can refer to different "code" (when
you override). I believe the reason is because when you do not override
a virtual method in the base class, the compiler (or early binding)
makes both objects "this" and "base" point to the same "code". But in
the case where you do override a virtual method in the derived class,
the compiler (or early bindig) makes each object (this AND base) point
to different methods (code).
Sorry for the long post but I decided to try to make some sense out of
this after I encountered a problem ( which I could've posted instead of
all this but decided against; in fear of being told "it's becase it's a
private". That alone, I believe is not a clear answer, but a vague one.
But anyways, I am going to include this code:
public class Car
{
private uint odometer;
}
public class RacingCar : Car
{
private uint odometer;
public static void Main( )
{
}
}
The above compliles with no errors and only two warnings (no
assignement). But the problem I see is this: Why do I *not* get an
error from the compiler, along the lines of "error: redefinition of
Car.odometer", because I inherit a member with the exact same signature
that's also declared in RacingCar? And as I said; someone looking at
this would probably say "because Car.odometer is private and it's
inside its own class scope". And it's true that it's within its own
scope, which would prove my theory of two seperate class objects
(through "base" and "this") exist when you have a derived class, but,
that alone is not enough of an answer to me so I wrote all this for
some enlightment and confirmationt. What's your take or view on this?
class in a derived class? I have a *theory* of how this works, of
which, I'm not completely sure of but makes logical sense to me. So,
I'm here for an answer (more of a confirmation), hopefully.
First let me say that I know people keep saying; it doesn't work
because the member "is a private". I believe there's more to it than
just simply that...
Theory: You inherit, not only the members in the base class, but the
whole base class itself - as an object, which contains the members.
Therefore, this has *almost* the same effect as if you declared a base
class manually in the derived class as shown in figure 1:
public class Base
{
private string name;
// more members and methods...
}
public class Derived
{
// instance members:
Base baseField;
private uint numbersField;
}
and if you tried to access the private member "name" of baseField
inside a method in the derived class like: baseField.string, you would
get an error, because it is private and can only be accessed within
it's own class scope (container). And similarly, this holds true for
why you cannot access a private base member in a derived class in a
"base and derived class relationship". This theory makes good, perfect
logical sense (to me) of why you *cannot* access a private member
*because* you're trying to access a private member outside of the
container where it is defined. And also, the keyword "base" then
essentially becomes the reference to that base class object. Just like
"this" is a reference to an instantiated object. And this(not the
keyword), also, essentially means this: when you derived a class from a
base class, you then have "two" classes within one unit, and this unit
is the drived class.
To elaborate some more, let's throw in a problematic problem:
So with that just said, How then does the keywords "base" and "this"
refer to the same "data" (fields etc..) and "code" (methods etc..) - at
times - when they *are* two different objects which are within one unit
- the derived class (this == drived class object AND base == base class
object)? But, they also, sometimes can refer to different "code" (when
you override). I believe the reason is because when you do not override
a virtual method in the base class, the compiler (or early binding)
makes both objects "this" and "base" point to the same "code". But in
the case where you do override a virtual method in the derived class,
the compiler (or early bindig) makes each object (this AND base) point
to different methods (code).
Sorry for the long post but I decided to try to make some sense out of
this after I encountered a problem ( which I could've posted instead of
all this but decided against; in fear of being told "it's becase it's a
private". That alone, I believe is not a clear answer, but a vague one.
But anyways, I am going to include this code:
public class Car
{
private uint odometer;
}
public class RacingCar : Car
{
private uint odometer;
public static void Main( )
{
}
}
The above compliles with no errors and only two warnings (no
assignement). But the problem I see is this: Why do I *not* get an
error from the compiler, along the lines of "error: redefinition of
Car.odometer", because I inherit a member with the exact same signature
that's also declared in RacingCar? And as I said; someone looking at
this would probably say "because Car.odometer is private and it's
inside its own class scope". And it's true that it's within its own
scope, which would prove my theory of two seperate class objects
(through "base" and "this") exist when you have a derived class, but,
that alone is not enough of an answer to me so I wrote all this for
some enlightment and confirmationt. What's your take or view on this?