As object-oriented developers, we are told to prefer composition over inheritance. But why?
As Ken Pugh states, refactoring into a hierarchy is much easier than refactoring out of a hierarchy. Starting down the interface-based route, you can get a feel whether inheritance is a better implementation option without actually committing. This holds true especially since inheritance is often abused.
A funny real-world parallel to this problem in software development is the naming of animal taxonomy. There is/was great discussion around renaming all the animals in the world. You see, the current naming system (the Linnaean system) uses a set of suffixes depending on the classification (ie... -ae). The problem is that as new species are discovered, they have caused ripple effects in the hierarchy. Adding a new parent into the hierarchy causes the children to change names (ie..the suffixes). This wreaks havoc on biology books, search engines, and a whole host of other non-related items (including legislation such as the one which protects endangered species). Needless to say, there are very real monetary effects to such a renaming.
This struck me as funny given that the same effect can be seen in software development. Prematurely using inheritance can cause lots of problems, including ripple effects on dependent classes. Many times this occurs as business requirements change (ie.. new species are discovered) or relationships are clarified.
I guess the biologists should take a lesson from OOP. They should have chosen composition over implementation inheritance. ;-)