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:

• Support all of the class invariants of the parent class.
• Support all of the class post-conditions of the parent class.
• Support all of the class preconditions of the parent class.

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.

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

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

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.

It is a problem of semantics.

I use inheritance whenever the parent class is a generalization of the descending class. The example given in Class::Delegation is not well chosen. A car can't inherit from a wheel. A car contains wheels. In this case you use delegation.

The appropriate example would be a class vehicle, from which you inherit to create car, truck, tractor, and so on. In this case, it makes sense to use inheritance.

My rule of thumb is, if it makes sense to say derived class IS A parent class, you inherit, otherwise you include the other class inside yours.

It makes sense to say a car is a vehicle, but it does not make sense to say a car is a wheel. Somebody could say that "a car is a wheel, a brake, an engine, and so on," and inherit from all the components. But also a washing machine can have wheels, engines and brakes, but it is not a car. Thus, the inheritance paradigm doesn't apply, and forcing it in such a case can only create confusion.

 _  _ _  _  
(_|| | |(_|><
 _|   

The orthodox teaching is, if it's an a-kind-of relationship, use inheritance; if has-a, use aggregation/composition; if an use relationship, use delegation.

But then, there is design vs implementation. Something could be conceptually inheritance; but delegation implementation could be "better," say, for performance or whatever. (Like, it seems to me not all DBAs favor OO SQL.)

Having to call an instance method through an object that's six or seven levels down the hierarchy is no fun.

The advocacy of the use of inheritance was pretty strong back in the 80's and early 90's. Nowadays, inheritance is more discouraged in many people's teaching in favor of, say, interface (as in Java).

Conceptually and practically, if you think about it, inheritance somewhat violates the very concept of encapsulation. It creates rather strong coupling between classes.

Granted, a change in the parent class automatically cascading to all its children could be a very desirable feature. It's useful when your requirements specification is stable enough. If not, if you need to make dramatic changes in the parents, it could break things everywhere else.

Sure, it breaks things too with delegation or interface, but presumeably since the delegator explicitly indicates which methods to import (and implement), at least, it's clearer where things are going to break.

Not necessarily good or bad, for me, as an development process, if I'm not sure what something is supposed to be for the moment, I tend to prefer to err by using something like delegation until it's rather clear that inheritance makes sense implementation-wise and design-wise (sounds like a backward process in fact).

(There are shove-it-down-your-throat kind of marketing fallacy and disinformation that OOPS and inheritance makes your application and code easier to use. Easy of use is the result of well thought out design and implementation, mostly regardless of the paradigm you're following.)

__________________
Update: Perhaps a digression. Somewhat unique to Perl few other languages share, the possibility of mixing procedural and OO style into the same module could be a neat and confusing feature.

It could be neat for instance (no pun intended) when you implement a least square regression module, only matrix in, matrix out. Procedural style is fine. But it would be nice when you "print" the result matrix, you get a summary instead of raw data. In that case, you need to overload the double quotes operator. Hence, you need to "bless" your output matrix into an object.

From the user's perspective, the module could look procedural except for the magical "print" feature. From the coder's perspective, the module is technically a bit of OO.

With such a module, inheritance becomes a boot point in Perl, especially since it could have subroutines in a module that aren't object's methods.

I certainly wouldn't say inheritance was evil, but it's not always the best solution.

In the context of Net::LDAP, it might be helpful to consider the various reasons people might subclass or encapsulate LDAP connections, and how those might work together.

For example, let's say that people have created several subclasses of Net::LDAP:
- one like yours, which adds some convenient high-level methods;
- one that better caches results to avoid repeated requests to the LDAP host; and
- one that proxies the LDAP requests over SOAP to a mod_perl server behind a firewall, where the LDAP server is located.

Ideally, I'd like to be able to get an object that has the Express interface, the Caching functionality, and the SOAPProxy implementation, but if they're all just simple subclasses of Net::LDAP, it's awkward to assemble such a beast. (Cf. "diamond pattern".) Perhaps you could accomplish it using mixin classes, but still, ick.

If each of those packages is implemented as a "decorator" or "proxy," using delegation, then things suddenly become simpler:

my $ldap_handle = Net::LDAP::Express->new( 
  debug => 0,
  target => Net::LDAP::Caching->new( 
    duration => 30,
    target => Net::LDAP::SOAPProxy->new( 
      soap_url => '...'
    )
  )
);
[download]

This kind of mix-and-match composition of functionality provides a combinatorial explosion of possibilities, rather than the incremental addition of a subclass.

Ideally, I'd like to be able to get an object that has the Express interface, the Caching functionality, and the SOAPProxy implementation, but if they're all just simple subclasses of Net::LDAP, it's awkward to assemble such a beast. (Cf. "diamond pattern".) Perhaps you could accomplish it using mixin classes, but still, ick.

While I agree that is is "ick" in Perl (and Java, and many other languages) and decorators are an excellent solution, this is more a language issue than an issue with multiple inheritance in general. In Eiffel, for example, it's very easy since you have a lot of explicit control over how multiple inheritance occurs.

Implementation inheritance/reuse - having written one pile of code, a similar pile (e.g. a superset) can be generated in a controlled manner, i.e. the code doesn't have to be copied and edited. A limited and peculiar kind of abstraction. (E.g. Java class inheritance.)

There's also specification inheritence there.

Brad

Consider typesafety.pm rather than Class::Contract. Not only does it declare what is passed and returned, but it enforces argument types and expected return types to match the declaration (I forgot to check actual return types - whoops - next version). All I ever do is shameless self-plug here - I'm really sorry. Since I try to write useful things, I like to think that now and again something might actually be useful.

Erm.

Class::Contract implements design by contract in perl - which has direct relevance to the inheritence vs delegation issue. Contracts help make the implicit contracts involved in isa relationships explicit in the code itself and encourage good use of inheritance and delegation.

typesafety, while cute, is to do with type safety - a completely separate issue. I don't see how it relates to the inheritence vs delegation issue. You can get in exactly the same mess in statically typed languages like C++ and Java.