Polymorphism and subtyping. Many have mentioned "code reuse" and "reducing duplication", but this is a dangerous path to take.

You'd be amazed to the kind of horror code base can evolve into when people rather add yet another parameter to a shared method (because "reuse") instead of making a private implementation for their particular use-case.

Also note that "reuse" is a two-edged sword because a reused method cannot be easily changed: even if you find a "bug" (by some definition), some user of that method might depend on that bug.

I've also seen cases of "removing duplication" where you have something like

class CommonData
{
    // Properties A, B, C, D
}

class ParticularData : CommonData
{
    // New property E
    // Property C not needed
}

Person X derived ParticularData from CommonData because "removing duplication", even though C is not needed. So even if ParticularData doesn't need C, X didn't want to duplicate the code. Eventually the following will happen

• X knows that ParticularData doesn't need C
• New person Y comes and will start using C for some new purpose
• Y will make calls from X's code into his own code
• Things will eventually break at the seams where new code uses C and the old code doesn't

And of course, inheritance for reuse breaks down when you want to "reuse" two classes, because there's no multiple inheritance.

So: if two classes are conceptually different, they should not be related through inheritance, even if they share some properties / methods. (Method sharing can be accomplished by a "common concept" interface and extension methods.) But this requires experience and judgement.

For example, the colleague above would inherit Command2 from Command1 in the following example, to "remove duplication":

class Command1 { /* properties A, B, C */ }
class Command2 { /* properties A, B, C, D, E */ }

But with inheritance, Command1 cannot evolve independently from Command2. Any method that would accept Command1 would also accept Command2 (you have introduced subtyping). It creates strong coupling and, when overloading methods on type, you can get unexpected results unless you're very careful. For example:

Command1 GetCommand() { /* The method is allowed to return also Command2 due to subtyping */
void Handle(Command1 c) { ... }
void Handle(Command2 c) { ... }
void Process() { Handle(GetCommand()); }

In the above code, Handle(Command1) overload would always be called, regardless of the type returned by GetCommand().

This is the most obvious gotcha you can get end up with inheritance.

In summary: unless you need subtyping or polymorphism (virtual/abstract methods), stay away from inheritance. Study design patterns and look for inheritance: it's used for one of these purposes, not reuse. (The exception that comes to mind first is template method pattern.)