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

Discussion in 'C++' started by Zero, Oct 18, 2006.

  1. Zero

    Zero Guest

    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;
    }
    Zero, Oct 18, 2006
    #1
    1. Advertising

  2. * 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?
    Alf P. Steinbach, Oct 18, 2006
    #2
    1. Advertising

  3. Zero

    Salt_Peter Guest

    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...
    Salt_Peter, Oct 18, 2006
    #3
  4. Zero

    Martin Steen Guest

    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
    Martin Steen, Oct 18, 2006
    #4
  5. Zero

    Zero Guest

    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.
    Zero, Oct 18, 2006
    #5
  6. Zero

    Ole Nielsby Guest

    "Zero" <> skrev i en meddelelse
    news:...
    > 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
    Ole Nielsby, Oct 18, 2006
    #6
  7. Zero

    Mike Wahler Guest

    "Zero" <> wrote in message
    news:...
    >
    > 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
    Mike Wahler, Oct 18, 2006
    #7
  8. Zero

    Salt_Peter Guest

    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?
    Salt_Peter, Oct 18, 2006
    #8
  9. Zero

    Zero Guest

    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!!
    Zero, Oct 19, 2006
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. marco

    dynamic import with heritage

    marco, Jun 10, 2004, in forum: Python
    Replies:
    8
    Views:
    579
    marco
    Jun 11, 2004
  2. bugzilla
    Replies:
    15
    Views:
    1,391
    Greg Comeau
    Mar 28, 2005
  3. Alexandre Badez

    Multi Heritage with slots

    Alexandre Badez, Sep 5, 2007, in forum: Python
    Replies:
    5
    Views:
    235
    Alexandre Badez
    Sep 5, 2007
  4. John Pritchard-williams

    Japanese Heritage of Ruby: useful by-product?....

    John Pritchard-williams, Aug 28, 2008, in forum: Ruby
    Replies:
    4
    Views:
    125
    Dido Sevilla
    Aug 29, 2008
  5. Vincent M.

    Troubles with objects heritage.

    Vincent M., Apr 27, 2004, in forum: Javascript
    Replies:
    1
    Views:
    77
    Michael Winter
    May 3, 2004
Loading...

Share This Page