Private Inheritance and Publice Inheritance

Discussion in 'C++' started by karthikbalaguru, Sep 3, 2007.

  1. Hi,
    Could someone here tell me some links/pdfs/tutorials to know about the
    difference between Private Inheritance and Public Inheritance ?
    I am unable to get info w.r.t it.

    Thx in advans,
    Karthik Balaguru
     
    karthikbalaguru, Sep 3, 2007
    #1
    1. Advertising

  2. karthikbalaguru

    Daniel T. Guest

    Daniel T., Sep 3, 2007
    #2
    1. Advertising

  3. karthikbalaguru wrote:
    > Could someone here tell me some links/pdfs/tutorials to know about the
    > difference between Private Inheritance and Public Inheritance ?
    > I am unable to get info w.r.t it.


    What book on C++ are you reading that doesn't explain the difference
    and the use of access specifiers when deriving?

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Sep 3, 2007
    #3
  4. karthikbalaguru

    SasQ Guest

    On Mon, 03 Sep 2007 10:19:45 -0700, karthikbalaguru wrote:

    > Could someone here tell me some links/pdfs/tutorials
    > to know about the difference between Private Inheritance
    > and Public Inheritance?


    Inheritance always means "IS A" relationship.
    E.g. "Porshe IS A Car".
    It means that Porshe could do all the things that
    all Cars can do.

    Apply public inheritance when you want to describe
    "IS A" relationshit to "whole world" ;) By writing
    class Porshe : public Car
    you say to everyone: "Porshe IS A Car".
    Thanks to public inheritance, which defines that
    kind of relationship, it's possible to use derived
    class [i.e. the Porshe] in every place where the
    Car is accepted, because every Porshe is also a Car ;)

    Private inherintance could restrict the knowledge
    about that family bonds only to the derived class.
    The rest of the world will know nothing about that
    relationship. The only thing which will be know that,
    will be the class's implementation, and only it
    will be able to use from that fact.

    Some people also asks what is the difference between
    private inheritance and composition. Some of them
    sees no difference at all, because they focus only
    on the fact that in both cases only the class's
    implementation can use the contained/base class.
    But there is one, very important difference:
    overriding virtual methods. You cannot ovverride
    a method of contained class, but you can do it
    with methods of the [even privately] interface
    derived from a base class.


    --
    SasQ
     
    SasQ, Sep 3, 2007
    #4
  5. On Sep 3, 11:14 pm, "Daniel T." <> wrote:
    > karthikbalaguru <> wrote:
    > > Could someone here tell me some links/pdfs/tutorials to know about the
    > > difference between Private Inheritance and Public Inheritance ?
    > > I am unable to get info w.r.t it.

    >
    > http://www.parashift.com/c -faq-lite/private-inheritance.html


    Thx for info.

    Karthik Balaguru
     
    karthikbalaguru, Sep 4, 2007
    #5
  6. karthikbalaguru

    SasQ Guest

    On Mon, 03 Sep 2007 14:14:49 -0400, Daniel T. wrote:

    > http://www.parashift.com/c -faq-lite/private-inheritance.html


    "(...)
    The 'Car has-a Engine' relationship can also be expressed
    using private inheritance:

    class Car : private Engine
    (...)"

    WHAT?! o_O
    What sense makes the above?
    The "has-a" relationshit is evidently a composition.
    If someone think different, let he try to think if
    the Car could have more than one engine. I haven't seen
    that kind of car, but if we do the same with the plane,
    we'll see that it could have more engines than one.
    How one could express that with use of [private] inheritance??
    It's impossible, ant that's the reason why it should be
    done with use of composition.

    There is other thing wrong in that example.
    It assumes that for the Car class's implementation
    the Engine is an ancestor. So, from the perspective
    of the implementation, Car is-a Engine [WTF?? LOL! :p].
    I didn't know that a Car is a special kind-of-an
    Engine, even if knowing that fact would be restricted
    only for private interface of the Car class.
    It's ridiculous!

    I think the more adequate example would be:

    class IllegalEmployee : private Employee

    ;D
    The IllegalEmployee knows that he is a kind of Employee.
    He is able to do what other legal employers do.
    But for wider public he is not an Employee ;) He
    doesn't confess that he is ;) Maybe some his friend
    class EmployeesFriend [;D] could make use of this
    fact, but not the others ;)

    --
    SasQ
     
    SasQ, Sep 4, 2007
    #6
  7. SasQ wrote:
    > On Mon, 03 Sep 2007 14:14:49 -0400, Daniel T. wrote:
    >
    >> http://www.parashift.com/c -faq-lite/private-inheritance.html

    >
    > "(...)
    > The 'Car has-a Engine' relationship can also be expressed
    > using private inheritance:
    >
    > class Car : private Engine
    > (...)"
    >
    > WHAT?! o_O
    > What sense makes the above?
    > The "has-a" relationshit is evidently a composition.


    So? The object is composed of its base class subobjects and data
    members. If I want to add an entity to my object, why couldn't
    I use inheritance?

    > If someone think different, let he try to think if
    > the Car could have more than one engine. I haven't seen
    > that kind of car, but if we do the same with the plane,
    > we'll see that it could have more engines than one.
    > How one could express that with use of [private] inheritance??


    Those are different engines, are they not? You have to have
    a way to identify engines, no? You can derive different classes
    for the "left" and "right" engine (or however else you identify
    them), and inherit from those.

    > It's impossible, ant that's the reason why it should be
    > done with use of composition.


    "Composition" and "private inheritance" are orthogonal concepts.
    You cannot set them _against_ each other.

    > There is other thing wrong in that example.
    > It assumes that for the Car class's implementation
    > the Engine is an ancestor. So, from the perspective
    > of the implementation, Car is-a Engine [WTF?? LOL! :p].
    > I didn't know that a Car is a special kind-of-an
    > Engine, even if knowing that fact would be restricted
    > only for private interface of the Car class.
    > It's ridiculous!


    I think you're (like many others before you) confuse some
    OO principles (and their applicability) with C++ language
    features that have never been intended to serve as the direct
    implementation of those principles. Just like many others you
    probably assume C++ an OOP language, which it isn't.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Sep 4, 2007
    #7
  8. karthikbalaguru

    James Kanze Guest

    On Sep 4, 12:15 am, SasQ <> wrote:
    > On Mon, 03 Sep 2007 10:19:45 -0700, karthikbalaguru wrote:
    > > Could someone here tell me some links/pdfs/tutorials
    > > to know about the difference between Private Inheritance
    > > and Public Inheritance?


    > Inheritance always means "IS A" relationship.
    > E.g. "Porshe IS A Car".
    > It means that Porshe could do all the things that
    > all Cars can do.


    C++ inheritance is an implementation technique in C++, to be
    used when appropriate. It doesn't "mean" anything, except that
    it was a convenient implementation technique. There is not
    necessarily a one to one relationship between C++ inheritance
    and OO derivation. It is exceedingly rare, of course, for OO
    derivation to be implemented with anything other than
    inheritance in C++, but I imagine that there are cases. And it
    is quite common for C++ inheritance to be used in cases other
    than OO derivation.

    In practice, if a class B "looks like" a base class (i.e. has a
    virtual destructor and at least some virtual functions), and the
    class D inherits publicly from B, then unless the documentation
    explicitly states otherwise, it's probably safe to assume that
    the inheritance is being used for OO derivation, and that the
    LSP holds (although of course, the language itself makes no
    guarantee). In general, one does not assume OO derivation, the
    LSP or "isA" otherwise. (And of course, any explicite
    documentation overrides all other considerations.)

    > Apply public inheritance when you want to describe
    > "IS A" relationshit to "whole world" ;) By writing
    > class Porshe : public Car
    > you say to everyone: "Porshe IS A Car".
    > Thanks to public inheritance, which defines that
    > kind of relationship, it's possible to use derived
    > class [i.e. the Porshe] in every place where the
    > Car is accepted, because every Porshe is also a Car ;)


    > Private inherintance could restrict the knowledge
    > about that family bonds only to the derived class.


    That is *not* the conventional use. The "conventional"
    statement is that public inheritance is inheritance of
    interface, private inheritance inheritance of implementation.

    > The rest of the world will know nothing about that
    > relationship. The only thing which will be know that,
    > will be the class's implementation, and only it
    > will be able to use from that fact.


    > Some people also asks what is the difference between
    > private inheritance and composition. Some of them
    > sees no difference at all, because they focus only
    > on the fact that in both cases only the class's
    > implementation can use the contained/base class.
    > But there is one, very important difference:
    > overriding virtual methods. You cannot ovverride
    > a method of contained class, but you can do it
    > with methods of the [even privately] interface
    > derived from a base class.


    Quite. Private inheritance implies a somewhat tighter binding
    than composition, and the general rule for implementation is to
    use composition when you can, and private inheritance when you
    have to.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Sep 4, 2007
    #8
  9. karthikbalaguru

    SasQ Guest

    On Tue, 04 Sep 2007 14:48:18 -0400, Victor Bazarov wrote:

    >> The "has-a" relationshit is evidently a composition.

    >
    > So? The object is composed of its base class subobjects
    > and data members.


    Technically, yes. But it's only "by accident" that
    inheritance is implemented that way in C++.

    > If I want to add an entity to my object, why couldn't
    > I use inheritance?


    Because using private inheritance for composition only to
    exploit the fact that inherited object becomes a part of
    the inheriting object, is some kind a "hack" for me.
    Private inheritance is something more than simple
    composition, as I've mentioned earlier. It has other
    semantics, produces tighter dependency bound between
    inheriting object and its base class, makes possibility
    to ovverride virtual methods, doesn't allow multiple
    instances of the base class contained in derived class etc.
    For me those are way too different concepts to use it
    interchangeably.

    > Those are different engines, are they not?


    Those are different INSTANCES of the same Engine class.
    They're not different CONCEPTS.

    > You have to have a way to identify engines, no?


    Yes. But according to my previous observation [different
    INSTANCES, not different CONCEPTS] I would express it
    in the following way:

    class Aeroplane
    {
    Engine leftOuter, leftInner, rightOuter, rightInner;
    };

    Try to do the same with inherintance ;J
    Even if you derive the Engine class multiple times,
    you won't be able to access to the particular engine
    by unique name.

    > You can derive different classes for the "left" and
    > "right" engine (or however else you identify them),
    > and inherit from those.


    My godess! :p So what BEHAVIOUR differs the left engine
    from right engine? :)

    > "Composition" and "private inheritance" are orthogonal
    > concepts. You cannot set them _against_ each other.


    I disagree. I treat private inheritance as a superset
    of simple composition [it's something more].

    > I think you're (like many others before you) confuse
    > some OO principles (and their applicability) with C++
    > language features that have never been intended to
    > serve as the direct implementation of those principles.


    So try to prove me my mistake ;)

    > Just like many others you probably assume C++ an OOP
    > language, which it isn't.


    C++ is a multiparadigm language. I know that it only SUPPORTS
    OOP techniques, but it would be unlogical to support it
    differently and in contradiction to the common sense ;J


    --
    SasQ
     
    SasQ, Sep 5, 2007
    #9
  10. karthikbalaguru

    Guest

    And yet, private inheritance is sometimes called implementation
    inheritance. It is equivalent to the composition with this
    restriction: the relation must be one-to-one.

    On 4 sep, 00:15, SasQ <> wrote:
    > On Mon, 03 Sep 2007 10:19:45 -0700, karthikbalaguru wrote:
    > > Could someone here tell me some links/pdfs/tutorials
    > > to know about the difference between Private Inheritance
    > > and Public Inheritance?

    >
    > Inheritance always means "IS A" relationship.
    > E.g. "Porshe IS A Car".
    > It means that Porshe could do all the things that
    > all Cars can do.
    >
    > Apply public inheritance when you want to describe
    > "IS A" relationshit to "whole world" ;) By writing
    > class Porshe : public Car
    > you say to everyone: "Porshe IS A Car".
    > Thanks to public inheritance, which defines that
    > kind of relationship, it's possible to use derived
    > class [i.e. the Porshe] in every place where the
    > Car is accepted, because every Porshe is also a Car ;)
    >
    > Private inherintance could restrict the knowledge
    > about that family bonds only to the derived class.
    > The rest of the world will know nothing about that
    > relationship. The only thing which will be know that,
    > will be the class's implementation, and only it
    > will be able to use from that fact.
    >
    > Some people also asks what is the difference between
    > private inheritance and composition. Some of them
    > sees no difference at all, because they focus only
    > on the fact that in both cases only the class's
    > implementation can use the contained/base class.
    > But there is one, very important difference:
    > overriding virtual methods. You cannot ovverride
    > a method of contained class, but you can do it
    > with methods of the [even privately] interface
    > derived from a base class.
    >
    > --
    > SasQ
     
    , Sep 10, 2007
    #10
    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. maxw_cc
    Replies:
    1
    Views:
    3,197
    Martijn van Steenbergen
    Dec 21, 2003
  2. qazmlp
    Replies:
    19
    Views:
    825
    Daniel T.
    Feb 4, 2004
  3. DaveLessnau
    Replies:
    3
    Views:
    447
    Howard
    May 16, 2005
  4. Jeremy Bowers
    Replies:
    3
    Views:
    555
    Steven Bethard
    Jan 24, 2005
  5. Daniel Finnie
    Replies:
    3
    Views:
    210
    Logan Capaldo
    Dec 16, 2006
Loading...

Share This Page