in reply to Inheritance vs Delegation: pros and cons

My advice would be to only use inheritance if your subclass really has an is-a relationship with the parent class.

Can you swap your class in when somebody else is using the parent class? If not, it's not an is-a relationship.

Thinking about classes with Design by Contract in mind often helps. A subclass should:

If this isn't true then inheritance can rapidly become a burden. You end up with a deep class hierarchy where the sub-sub-sub-class does something completely different from original parent class.

Concerns aren't separated in the code, maintenance becomes a nightmare, and you rapidly create a big ball of mud.

I'm not anti-inheritance (hell, I even think multiple inheritance is a good thing :-) but it should only be used for is-a relationships. Anything else is asking for trouble.

  • Comment on Re: Inheritance vs Delegation: pros and cons

Replies are listed 'Best First'.
Re: Re: Inheritance vs Delegation: pros and cons
by dragonchild (Archbishop) on Jul 28, 2003 at 15:38 UTC
    (hell, I even think multiple inheritance is a good thing :-)

    I would agree here, with the caveat that inheritance should be governed by interfaces. For example, one could say that a hovercraft is-a LandVehicle and is-a WaterVehicle. The differences between LandVehicle and WaterVehicle need to be orthogonal, with that any overlap is atomic.

    Explanation of my butchering of English:

    • If both LandVehicle and WaterVehicle have method XYZ, XYZ does the same type of action for both. Any added features for one can be overloaded, as necessary.
    • If WaterVehicle has method ABC that LandVehicle does not, it does something (and only that thing) that LandVehicle cannot do (such as Dive() or DumpBallast() or the like). It shouldn't be something like SlowDown() where LandVehicle has ApplyBrakes().
    Multiple inheritance, in my mind, adds several layers of complexity and programmer work that needs to be thoroughly vetted before being approved. That said, there are a few situations where it's warranted.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]

      I usually judge when it is becoming evil by the amount of method overridiing that has to be done. If you find yourself overridding nearly every method with functionality that is completely different to the parent then you are in an evil place. If however your method overriding is mainly introducing a bit of polymorphism and extending methods to handle extended structures in your object then I think you are in a good place.

      Thats just a personal metric based on lazyness. I agree multiple inheritance is good and a nice way to package together your clasess.

      not too sure bout delegation will need to check that oot sounds like it's just run time method dispatch

[reply]

      It sounds like you're talking about "contracts" here not "interfaces" (as I understand the term).

      The interface term usually refers to the method signatures of a class, and these days is pretty much synonymous with the Java system of not having multiple inheritance of behaviour - just interface. Which, as a way of avoiding the problems with multiple inheritance, is throwing the baby away with the bathwater as far as I'm concerned.

      Just looking at method signatures isn't enough to figure out whether XYZ "does the same action". This is where contracts can be useful. You explicitly state in your pre-conditions and post-conditions what the requirements and result of the method should be.

      Many of the problems that occur with multiple inheritance in languages like Java and Perl disappear in languages like Sather and Eiffel where you have contracts (to keep you using inheritance only when appropriate) and support for multiple inheritance (allowing good resolution of naming issues, diamond inheritance, etc.) built into the core language.

[reply]

In Section Meditations