Multiple base classes in .NET - Framework and Interface Programming

This is a discussion on Multiple base classes in .NET - Framework and Interface Programming ; Hello, I agree with the quote "designers overuse inheritance as a reuse technique." One could qualify that by saying "inexperienced designers." We should not conclude that aggregation is preferable to inheritance in all contexts. Such a conclusion favors a "principle" ...

+ Reply to Thread
Page 8 of 8 FirstFirst ... 6 7 8
Results 71 to 79 of 79

Multiple base classes in .NET

  1. Default Re: Multiple base classes in .NET

    Hello,

    I agree with the quote "designers overuse inheritance as a reuse
    technique." One could qualify that by saying "inexperienced designers."

    We should not conclude that aggregation is preferable to inheritance in all
    contexts. Such a conclusion favors a "principle" (favor composition) over
    the motivation behind the principle (inheritance abuse).

    Not all use of inheritance is abuse. Mixins are no more susceptible to abuse
    that other code reuse techniques. Ask people who work in languages with good
    mixin support if mixins cause more problems than aggregation.

    The Gof book is not a bible. It represents a set of opinions at a particular
    point in history. At that point in time, static class diagrams (uml) were
    becoming popular. People often assumed they needed to create the class
    diagram up front, before implementing any of the leaves in the class
    hierarchy.

    Regards,
    Frank Hileman

    check out VG.net: http://www.vgdotnet.com
    Animated vector graphics system
    Integrated Visual Studio graphics editor

    "Richard" <legalize+jeeves@mail.xmission.com> wrote in message
    news:eipj94XzHHA.536@TK2MSFTNGP06.phx.gbl...
    > "That leads us to our second principle of object-oriented design:
    >
    > Favor object composition over class inheritance."
    >
    > So, no, they're not weaselling their way out of it by qualifying it as
    > public inheritance.
    >
    > They go on to say:
    >
    > "[...] our experience is that designers overuse inheritance as a
    > reuse technique, and designs are often made more reusable (and
    > simpler) by depending more on object composition."




  2. Default Re: Multiple base classes in .NET

    [Please do not mail me a copy of your followup]

    "Frank Hileman" <frankhil@no.spamming.prodigesoftware.com> spake the secret code
    <#MTYrUgzHHA.464@TK2MSFTNGP02.phx.gbl> thusly:

    >I agree with the quote "designers overuse inheritance as a reuse
    >technique." One could qualify that by saying "inexperienced designers."


    I don't know that this qualification is of much use since everyone
    starts out as an inexperienced designer. The problem I have seen is
    that people build up bad habits while inexperienced and then after
    having used these bad habits for a long time, they call themselves
    experienced, yet they are still a poor designer.

    >We should not conclude that aggregation is preferable to inheritance in all
    >contexts.


    That's why its a *preference* and not an outright ban on inheritance.

    >The Gof book is not a bible. [...]


    There's no reason to get insulting by bringing religion into it.
    --
    "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
    <http://www.xmission.com/~legalize/book/download/index.html>

    Legalize Adulthood! <http://blogs.xmission.com/legalize/>

  3. Default Re: Multiple base classes in .NET

    > Well, I've always heard that _public_ inheritance must be restricted to
    > cases of is-a. But surely there are cases when protected inheritance is
    > appropriate but public is not. For instance, if you are exposing a
    > readonly collection to your users, it may be helpful to inherit a full
    > featured collection privately, but make only the get accessors visible.


    > Sure, you could use aggregation/forwarding, but here the object is-a
    > readonly collection and also is-a writable collection, depending on the
    > user. That to me just sounds like protected inheritance. Of course, you
    > expose all the mutation functionality to your creator/owner by returning a
    > pair of pointers from a factory method, one cast to the mutable base class
    > and one not.
    >
    > Sadly, none of this is possible in .NET.


    I don't think a language should restrict a user from doing this type of
    thing but I personally find it extremely ugly. IMO (and it is a religious
    issue) an interface is something that the "public" deals with and they
    shoulsn't see anything else. If I use a vending machine to "download" a soft
    drink, I want to see the interface only - coin slot, selection buttons,
    change drop, etc. I don't want to see a second interface jutting out that
    has meaning to the manufacuter only (even if I can't use it). It's unsightly
    and confusing. The whole thing should be hidden which is not the case with
    protected or private inheritance. Your own collection example is very ugly
    in practice for instance (IMHO). This is because inheritance of this type
    isn't normally done to extend a base class' behaviour by adding extra
    functionality or even overriding existing behaviour. It's normally done to
    support a new and specifc implementation meaning your new class requires its
    own independent interface. A generic collection class for instance (say a
    "vector" that actually supported derivation) will have many different
    functions which become off-limits the moment I create a specific collection
    of type T. My new collection is designed to handle T only which usually
    involves very specific behaviour. It's not a "vector" from the user's
    standpoint and shouldn't be seen that way. It's a collection of T and that's
    how you want your users to see it (not as a "vector" even if it's
    protected/private - it still violates the "is a" relationship from their
    perspective). I also may not want them invoking the base class' "erase"
    function, "capacity" function, "reserve" function, etc. I can inherit from
    "vector" using "protected" or "private" and only expose what I want but
    users can still see it's a "vector" which is an implementation detail they
    shouldn't know about (especially since its functionality is off-limits). If
    I add my own "erase" function for instance (maybe even calling it "delete")
    then they'll now see two "erase" functions even if only one is accessible.
    The entire situation is completely unnatural and confusing notwithstanding
    the inconvenenience of aggregation since it requires new wrapper functions
    you get for free using inheritance (although even with inheritance you may
    need to replace a non-virtual base class function which leads to hiding
    issues and/or dual functions in the derived class - this can result in
    confusion and difficuties understanding the class even for those maintaining
    it). Nevertheless, I readily acknowledge that aggregation is a maintenance
    problem since you can wind up with many wrappers which often do little more
    than delegate to others (resulting in code bloat, maintenance problems,
    etc.).



  4. Default Re: Multiple base classes in .NET

    Ben, you mentioned public, private and protected inheritance. My
    understanding is that there is no conceivable use for protected inheritance,
    and, indeed, Stroustrup felt that was a mistake.

    ///ark



  5. Default Re: Multiple base classes in .NET


    "Larry Smith" <no_spam@_nospam.com> wrote in message
    news:ese$6wgzHHA.1184@TK2MSFTNGP04.phx.gbl...
    >> Well, I've always heard that _public_ inheritance must be restricted to
    >> cases of is-a. But surely there are cases when protected inheritance is
    >> appropriate but public is not. For instance, if you are exposing a
    >> readonly collection to your users, it may be helpful to inherit a full
    >> featured collection privately, but make only the get accessors visible.

    >
    >> Sure, you could use aggregation/forwarding, but here the object is-a
    >> readonly collection and also is-a writable collection, depending on the
    >> user. That to me just sounds like protected inheritance. Of course, you
    >> expose all the mutation functionality to your creator/owner by returning
    >> a pair of pointers from a factory method, one cast to the mutable base
    >> class and one not.
    >>
    >> Sadly, none of this is possible in .NET.

    >
    > I don't think a language should restrict a user from doing this type of
    > thing but I personally find it extremely ugly. IMO (and it is a religious
    > issue) an interface is something that the "public" deals with and they
    > shoulsn't see anything else. If I use a vending machine to "download" a
    > soft drink, I want to see the interface only - coin slot, selection
    > buttons, change drop, etc. I don't want to see a second interface jutting
    > out that has meaning to the manufacuter only (even if I can't use it).
    > It's unsightly and confusing. The whole thing should be hidden which is
    > not the case with protected or private inheritance. Your own collection
    > example is very ugly


    You were completely right... up until here. Non-public inheritance is
    hidden from the user. Only members can cast to a private/protected base
    class.

    > in practice for instance (IMHO). This is because inheritance of this type
    > isn't normally done to extend a base class' behaviour by adding extra
    > functionality or even overriding existing behaviour. It's normally done to
    > support a new and specifc implementation meaning your new class requires
    > its own independent interface. A generic collection class for instance
    > (say a "vector" that actually supported derivation) will have many
    > different functions which become off-limits the moment I create a specific
    > collection of type T. My new collection is designed to handle T only which
    > usually involves very specific behaviour. It's not a "vector" from the
    > user's standpoint and shouldn't be seen that way. It's a collection of T
    > and that's how you want your users to see it (not as a "vector" even if
    > it's


    That's how they would see it -- via the public interfaces it implements.

    > protected/private - it still violates the "is a" relationship from their
    > perspective). I also may not want them invoking the base class' "erase"
    > function, "capacity" function, "reserve" function, etc. I can inherit from
    > "vector" using "protected" or "private" and only expose what I want but
    > users can still see it's a "vector" which is an implementation detail they


    How? Protected/private base classes are implementation details and as such
    are hidden from the user.

    > shouldn't know about (especially since its functionality is off-limits).
    > If I add my own "erase" function for instance (maybe even calling it
    > "delete") then they'll now see two "erase" functions even if only one is
    > accessible.


    Functions in derived classes with the same name but different signatures
    hide base members, they do not overload. This is why.

    > The entire situation is completely unnatural and confusing notwithstanding
    > the inconvenenience of aggregation since it requires new wrapper functions
    > you get for free using inheritance (although even with inheritance you may
    > need to replace a non-virtual base class function which leads to hiding
    > issues and/or dual functions in the derived class - this can result in
    > confusion and difficuties understanding the class even for those
    > maintaining



    The using statement is a lot easier to maintain than a whole barrage of
    trivial forwarders.

    > it). Nevertheless, I readily acknowledge that aggregation is a maintenance
    > problem since you can wind up with many wrappers which often do little
    > more than delegate to others (resulting in code bloat, maintenance
    > problems, etc.).




  6. Default Re: Multiple base classes in .NET


    "Mark Wilden" <mwilden@communitymtm.com> wrote in message
    news:%23eIE7chzHHA.2312@TK2MSFTNGP05.phx.gbl...
    > Ben, you mentioned public, private and protected inheritance. My
    > understanding is that there is no conceivable use for protected
    > inheritance, and, indeed, Stroustrup felt that was a mistake.


    To specify the base class of a template class, where the exact class is
    chosen by a descendant.

    template <typename T>
    class S : protected T
    {
    };

    class R : S<std::vector<Q>>
    {
    };

    Naturally the class choosing the base class should have access to it, but
    with private inheritance, R couldn't use std::vector<Q>.



  7. Default Re: Multiple base classes in .NET

    Hi Richard,

    Sorry, I meant bible in the slang sense. GoF should not be considered a
    source of absolute wisdom.

    Frank

    "Richard" <legalize+jeeves@mail.xmission.com> wrote in message
    news:%23$$velgzHHA.5772@TK2MSFTNGP02.phx.gbl...
    >>The Gof book is not a bible. [...]

    >
    > There's no reason to get insulting by bringing religion into it.




  8. Default Brass air fittig

    Now that is a lot of brass air fittings Wholesale Tools With Free Shipping World Wide From China Distributor there is just about every type
    of air fitting that you could want. Wholesale prices too. I guess these could be used as small water pipe fitting also. I
    used some of the parts to make my babington wvo bu

  9. Default Brass air fittighttp://www.liangdianup.com/subpages/airfitting_1.htm

    Now that is a lot of brass air fittings there is just about every type
    of air fitting that you could want. Wholesale prices too. I guess these could be used as small water pipe fitting also. I
    used some of the parts to make my babington wvo bu

+ Reply to Thread
Page 8 of 8 FirstFirst ... 6 7 8

Similar Threads

  1. Replies: 2
    Last Post: 10-05-2007, 04:11 AM
  2. Multiple Base Classes in .Net
    By Application Development in forum DOTNET
    Replies: 9
    Last Post: 07-23-2007, 01:17 PM
  3. Multiple base classes in .NET
    By Application Development in forum DOTNET
    Replies: 0
    Last Post: 07-13-2007, 06:49 PM
  4. Re: Voluntary Abstract Base Classes
    By Application Development in forum Python
    Replies: 0
    Last Post: 06-29-2007, 01:37 PM
  5. Layout of base classes within derived classes
    By Application Development in forum c++
    Replies: 19
    Last Post: 01-17-2007, 11:17 AM