!!!Simple question on heritage or just misunderstanding!!!

[Zero]

Hello everyone,
here I have an example for heritage and I wonder
why the the object of type Down is able to change the private
attributes
from Above. Because I thought, when using heritage, the private
attributes
of Above are not useable. Can anybody remove my misunderstanding??

EXAMPLE:
#include <cstdlib>
#include <iostream>

using namespace std;

class Above
{
private:
int iTest1;
int iTest2;
public:
void setVars(int a, int b)
{
iTest1 = a;
};
};

class Down : public Above
{

};

int main(int argc, char *argv[])
{
Above a;
Down b;

b.setVars(4,5);

return EXIT_SUCCESS;
}

 

[Alf P. Steinbach]

* Zero:

Hello everyone,
here I have an example for heritage and I wonder
why the the object of type Down is able to change the private
attributes
from Above. Because I thought, when using heritage, the private
attributes
of Above are not useable. Can anybody remove my misunderstanding??

EXAMPLE:
#include <cstdlib>
#include <iostream>

using namespace std;

class Above
{
private:
int iTest1;
int iTest2;
public:
void setVars(int a, int b)
{
iTest1 = a;
};
};

class Down : public Above
{

};

int main(int argc, char *argv[])
{
Above a;
Down b;

b.setVars(4,5);

return EXIT_SUCCESS;
}

Consider that even though you can't control a dog's limbs directly (that
would entail accessing the dog's internal nervous system), you can tell
a dog to jump or lie down, using the the dog's public interface to the
world, and the dog will then, if it's well-behaved, /itself/ order its
limbs to do whatever you want -- and much better than you could have
controlled them directly if you had access.

 

[Salt_Peter]

Hello everyone,
here I have an example for heritage and I wonder
why the the object of type Down is able to change the private
attributes
from Above. Because I thought, when using heritage, the private
attributes
of Above are not useable. Can anybody remove my misunderstanding??

EXAMPLE:
#include <cstdlib>
#include <iostream>

using namespace std;

class Above
{
private:
int iTest1;
int iTest2;
public:
void setVars(int a, int b)
{
iTest1 = a;
};
};

class Down : public Above
{

};

int main(int argc, char *argv[])
{
Above a;
Down b;

b.setVars(4,5);

return EXIT_SUCCESS;
}

If you take your old car and give it a new paint job, new mags, brand
new suspension, add a sport exhaust, neon lights, a wicked sound system
and change the sprak plugs too, what are the chances that the ignition
keyslot will still accept your old car keys?

Now, the word heritage is what is bugging me and probably causes some
of your missunderstanding.
We say inheritance instead to describe a transposition, not something
you gained from some disgusting relative.
Heritage might best be replaced by transmission here, and i'm not
refering to the new transmission in the car either. Heritage is rather
composition as in a person has_a heritage but a person inherits
features from his parent's genes.

About your choice of Class names...
Down should not be deriving from Above in your class hierarchy. Down is
a Direction and Above is a relative position. These are unrelated.
Derivatives are not written to express differences, they express
commonality and specializations.

You could argue:

class Direction
{
};

class Up : public Direction
{
};

class Down : public Direction
{
};

etc...

 

[Martin Steen]

Hello everyone,
here I have an example for heritage and I wonder
why the the object of type Down is able to change the private
attributes
from Above. Because I thought, when using heritage, the private
attributes
of Above are not useable. Can anybody remove my misunderstanding??

There are two simple rules:

- a class can change all it's own attributes
- a class can call all methods of it's baseclass that
are public or protected, if the baseclass is public.

Because "setVars" is public, "Down" can call "setVars".
What happens inside "setVars" is a like a blackbox
for "Down".

-Martin

 

[Zero]

Hello everyone,
here I have an example for heritage and I wonder
why the the object of type Down is able to change the private
attributes
from Above. Because I thought, when using heritage, the private
attributes
of Above are not useable. Can anybody remove my misunderstanding??

EXAMPLE:
#include <cstdlib>
#include <iostream>

using namespace std;

class Above
{
private:
int iTest1;
int iTest2;
public:
void setVars(int a, int b)
{
iTest1 = a;
};
};

class Down : public Above
{

};

int main(int argc, char *argv[])
{
Above a;
Down b;

b.setVars(4,5);

return EXIT_SUCCESS;
}

If you take your old car and give it a new paint job, new mags, brand
new suspension, add a sport exhaust, neon lights, a wicked sound system
and change the sprak plugs too, what are the chances that the ignition
keyslot will still accept your old car keys?

Now, the word heritage is what is bugging me and probably causes some
of your missunderstanding.
We say inheritance instead to describe a transposition, not something
you gained from some disgusting relative.
Heritage might best be replaced by transmission here, and i'm not
refering to the new transmission in the car either. Heritage is rather
composition as in a person has_a heritage but a person inherits
features from his parent's genes.

About your choice of Class names...
Down should not be deriving from Above in your class hierarchy. Down is
a Direction and Above is a relative position. These are unrelated.
Derivatives are not written to express differences, they express
commonality and specializations.

You could argue:

class Direction
{
};

class Up : public Direction
{
};

class Down : public Direction
{
};

etc...

But why is it allowed that a class child
which inherits private attributes from a class base
can use this private attributes. Is there no conflict with
encapsulation.
Private attributes which are hidden are allowed to be used in
the class child?? This is not logical.

 

[Ole Nielsby]

Hello everyone,
here I have an example for heritage and I wonder
why the the object of type Down is able to change the private
attributes
from Above. Because I thought, when using heritage, the private
attributes
of Above are not useable. Can anybody remove my misunderstanding??

The point of clothing is not to make your "private attributes" unusable.
They can still be affected by others - but you decide.

In your example, the Above class has decided you can set its
private attribute, by exposing a public method.

You might later redesign Above to use a floats or a doubles, or
even strings, to store the value internally. The Down class would
not be affected as long as the setVars method still accepts ints - and
this is what encapsulation is about: you can change the internals
of a class without breaking other classes.

HTH/Ole Nielsby

 

[Mike Wahler]

Hello everyone,
here I have an example for heritage and I wonder
why the the object of type Down is able to change the private
attributes
from Above. Because I thought, when using heritage, the private
attributes
of Above are not useable. Can anybody remove my misunderstanding??

EXAMPLE:
#include <cstdlib>
#include <iostream>

using namespace std;

class Above
{
private:
int iTest1;
int iTest2;
public:
void setVars(int a, int b)
{
iTest1 = a;
};
};

class Down : public Above
{

};

int main(int argc, char *argv[])
{
Above a;
Down b;

b.setVars(4,5);

return EXIT_SUCCESS;
}

If you take your old car and give it a new paint job, new mags, brand
new suspension, add a sport exhaust, neon lights, a wicked sound system
and change the sprak plugs too, what are the chances that the ignition
keyslot will still accept your old car keys?

Now, the word heritage is what is bugging me and probably causes some
of your missunderstanding.
We say inheritance instead to describe a transposition, not something
you gained from some disgusting relative.
Heritage might best be replaced by transmission here, and i'm not
refering to the new transmission in the car either. Heritage is rather
composition as in a person has_a heritage but a person inherits
features from his parent's genes.

About your choice of Class names...
Down should not be deriving from Above in your class hierarchy. Down is
a Direction and Above is a relative position. These are unrelated.
Derivatives are not written to express differences, they express
commonality and specializations.

You could argue:

class Direction
{
};

class Up : public Direction
{
};

class Down : public Direction
{
};

etc...

But why is it allowed that a class child
which inherits private attributes from a class base
can use this private attributes. Is there no conflict with
encapsulation.
Private attributes which are hidden are allowed to be used in
the class child?? This is not logical.

Sure it is. Note that you can also do the same with the
parent as you did with the child, i.e. call the *public*
function 'setVars()'. Your data is 'private', but the
interface is 'public' (as you've defined it).

What the child class (or any other class' functions or any
non-member function cannot do, is access your parents' private
members.

class A
{
int i;
public:
void f()
{
i = 0; // OK, 'A' members have access to A's private members
}
};

class B : public A
{
void g()
{
i = 0; // ERROR, 'B' has no access to 'A's private members
f(); // OK, function 'A::f()' is defined as 'public'
}
public:
void h()
{
g(); // OK, 'B' members have access to B's private members
}
};

int main()
{
A a;
B b;
a.i = 0; // ERROR, 'A::i' is private
a.f(); // OK, 'A::f()' is public
b.g(); // ERROR, 'B::g()' is private
b.h(); // OK, 'B::h()' is public
return 0;
}

-Mike

 

[Salt_Peter]

Hello everyone,
here I have an example for heritage and I wonder
why the the object of type Down is able to change the private
attributes
from Above. Because I thought, when using heritage, the private
attributes
of Above are not useable. Can anybody remove my misunderstanding??

EXAMPLE:
#include <cstdlib>
#include <iostream>

using namespace std;

class Above
{
private:
int iTest1;
int iTest2;
public:
void setVars(int a, int b)
{
iTest1 = a;
};
};

class Down : public Above
{

};

int main(int argc, char *argv[])
{
Above a;
Down b;

b.setVars(4,5);

return EXIT_SUCCESS;
}

If you take your old car and give it a new paint job, new mags, brand
new suspension, add a sport exhaust, neon lights, a wicked sound system
and change the sprak plugs too, what are the chances that the ignition
keyslot will still accept your old car keys?

Now, the word heritage is what is bugging me and probably causes some
of your missunderstanding.
We say inheritance instead to describe a transposition, not something
you gained from some disgusting relative.
Heritage might best be replaced by transmission here, and i'm not
refering to the new transmission in the car either. Heritage is rather
composition as in a person has_a heritage but a person inherits
features from his parent's genes.

About your choice of Class names...
Down should not be deriving from Above in your class hierarchy. Down is
a Direction and Above is a relative position. These are unrelated.
Derivatives are not written to express differences, they express
commonality and specializations.

You could argue:

class Direction
{
};

class Up : public Direction
{
};

class Down : public Direction
{
};

etc...

But why is it allowed that a class child
which inherits private attributes from a class base
can use this private attributes. Is there no conflict with
encapsulation.

No, there is no conflict whatsoever. If Base does not provide access to
its internals, Child will never be able to access those either.

class Base
{
int n;
};

class Child : public Base
{
// can't access n, but it DOES have n.
};

Private attributes which are hidden are allowed to be used in
the class child?? This is not logical.

Its not allowed, you don't understand. Its Base that decides if Child
can access to its private parts. The class Child does not decide what
it has access to, even when it inherits publicly. The Child class
inherits the *privilege* _if_ the Base class supplies it.

Take a constructor, for example, if you write a public constructor that
sets a private integer, is that constructor not available? Is the
constructor not public? yes it is. Why should the Child class not be
allowed to use a publicly available constructor? After all, the Child
class is not accessing anything private, is it? Yet... look what
happens...

class Base
{
int n;
public:
Base( int x ) : n(x) { } // Base constructor sets private integer,
so n = x
};

class Child : public Base
{
public:
Child() : Base( 100 ) { } // Child ctor invokes Base ctor with a
const value,
}; // so x = 100, automatically

int main()
{
Child instance; // now instance has a private integer automatically
set to 100
// and nobody can modify that integer, nobody can
even read it.
// not even instance can access it

Child array[10]; // all 10 elements automatically have a private
integer set to 100
// again, no-one can even read the
integers
}

Even if you write a void setVar( int val ) member function in Child,
you still can't modify what is in its Base. Only Base is allowed to
provide that privelege. Is that not absolutely perfect logic?

 

[Zero]

Hello everyone,
here I have an example for heritage and I wonder
why the the object of type Down is able to change the private
attributes
from Above. Because I thought, when using heritage, the private
attributes
of Above are not useable. Can anybody remove my misunderstanding??

EXAMPLE:
#include <cstdlib>
#include <iostream>

using namespace std;

class Above
{
private:
int iTest1;
int iTest2;
public:
void setVars(int a, int b)
{
iTest1 = a;
};
};

class Down : public Above
{

};

int main(int argc, char *argv[])
{
Above a;
Down b;

b.setVars(4,5);

return EXIT_SUCCESS;
}

Thank you all very much for your great support. I realized
that I had a big misunderstanding. You are great!!