Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > !!!Simple question on heritage or just misunderstanding!!!

Reply
Thread Tools

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

 
 
Zero
Guest
Posts: n/a
 
      10-18-2006
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;
}

 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      10-18-2006
* 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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
 
 
 
Salt_Peter
Guest
Posts: n/a
 
      10-18-2006
Zero wrote:
> 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...

 
Reply With Quote
 
Martin Steen
Guest
Posts: n/a
 
      10-18-2006
Zero wrote:
> 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


 
Reply With Quote
 
Zero
Guest
Posts: n/a
 
      10-18-2006

Salt_Peter schrieb:

> Zero wrote:
> > 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.

 
Reply With Quote
 
Ole Nielsby
Guest
Posts: n/a
 
      10-18-2006

"Zero" <(E-Mail Removed)> skrev i en meddelelse
news:(E-Mail Removed) oups.com...
> 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


 
Reply With Quote
 
Mike Wahler
Guest
Posts: n/a
 
      10-18-2006

"Zero" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
>
> Salt_Peter schrieb:
>
>> Zero wrote:
>> > 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



 
Reply With Quote
 
Salt_Peter
Guest
Posts: n/a
 
      10-18-2006

Zero wrote:
> Salt_Peter schrieb:
>
> > Zero wrote:
> > > 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?

 
Reply With Quote
 
Zero
Guest
Posts: n/a
 
      10-19-2006

Zero schrieb:

> 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!!

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Multi Heritage with slots Alexandre Badez Python 5 09-05-2007 01:34 PM
How to implement C++ class heritage properties in C using C struct? bugzilla C Programming 15 03-28-2005 03:23 PM
dynamic import with heritage marco Python 8 06-11-2004 10:38 PM
The digital revolution is creating a gaping hole in our heritage Fuzzy Logic Digital Photography 11 05-02-2004 04:57 PM



Advertisments