Incipient Thoughts makes a point about inheritance and polymorphism that points out a problem common to OO development - without regard to implementation language:

In every OO class I teach, I introduce encapsulation and polymorphism as the primary OO tactics, with inheritance a distant third. It's hard to tease apart polymorphism and inheritance, because most OO languages are based on an intimate fusion of the two, unnecessarily.

Inheritance is a very strong relationship between objects. It makes it hard to tease anything apart. Some people experience maintenance problems as a result of pervasive inheritance in OO systems. Justifiably, these people then become skeptical about polymorphism as well, because it is so strongly linked to inheritance. They are then tempted to give up on OO altogether. This is throwing the baby out with the bathwater.

The two don't have to be so tightly linked, and - in the place OO originated (Smalltalk) - they really aren't. I have plenty of polymorphic objects in BottomFeeder that have no inheritance relationship at all. However, the two are commonly linked in the teaching of OO, and it's not unusual to see large inheritance trees in Smalltalk projects. Which is too bad, because Smalltalk makes ad-hoc polymorphism far easier to achieve than Java, C# - you don't have to go out of your way to define a formal interface, for instance.

There's a good example in the post using an "edit" feature of a Wiki, which points out how inheritance is an unnecessary complexity in this case.