in reply to Re: Inheritance vs Delegation: pros and cons
in thread Inheritance vs Delegation: pros and cons

(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:

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.

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

Replies are listed 'Best First'.
Re: Re: Re: Inheritance vs Delegation: pros and cons
by hakkr (Chaplain) on Jul 28, 2003 at 15:58 UTC

    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

Re^3: Inheritance vs Delegation: pros and cons
by adrianh (Chancellor) on Jul 29, 2003 at 09:31 UTC

    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.