The article is correct, assuming you read it.
Note that it is talking about "extends", which is one type of inheritance. Java's "interface" and "implements" are another type of inheritance.
...
Generally speaking, everything is evil if you don't understand it. Elements of OOP, recently hyped DoD and many other techniques - they all exists for some reason. They haven't been created to replace each other but rather to solve certain problems. Recently you may read on GD forums how programmers try to implement DoD without any valid use-case, at all cost, just because it sounds modern and makes impression of solving all world's problems. It's simply not true. DoD exists to solve certain set of problems while it may actually complicate other matters. Same goes to the inheritance. Programming is not black and white. You may successfully join techniques of using inheritance and composition etc. It's up to you what kind of architecture you built. Build it crafted to your needs not to current fashion :)
Answering you question I would say, inheritance isn't evil. As was mentioned above, everything may be used or abused. I agree with that 100%.
You don't kill a fly with an elephant gun. But sometimes. Just sometimes. You find yourself up against an elephant.
PS - it's a goddamn metafor.
"I think the whole cat in the box idea is one of them metaphors," said Albert.AH. A LIE.
cons
large inheritance can create higher coupling between classes.
root of hierarchy becomes deprecated = cascading affect on subclasses
could reveal encapsulated items
other cascading changes = change one class have to change more
large inheritance hard to understand whats going on behind the scenes with bottom classes
so in other words smaller inheritance is better.
you shouldnt always avoid inheritance. especially if you want to save time doing something simple.
like creating ten different animals who each have a different traits , do you really want to have to code what an animal is for each animal or just extend the animal class for each animal.
id say you should avoid large complex inheritance within an API if you are working on a long term project where the team will be changing.
if you are working with the same team or by yourself for the entire project and everybody's brain can handle the large hierarchy then its not a serious problem, but still possibly a bad design.
When you need to bridge two different object hierarchies it becomes an angel.
e.g. Suppose you were working on a project that mates Simulink to DirectShow.
You can do it with composition but that will be almost twice as work as you emulate a DirectShow filter on the Simulink side to serve as a sink for the composed filter - as opposed to directly making a DirectShow sink filter that dumps the data into the Simulink data flow (for which you would already have a base-class written to interface with Mathworks's C API.)
A good rule of thumb is to solve any problem with the least-powerful tool it can be (reasonably) solved with. Try not to think of that in a negative light -- by using the least-powerful tool, what we really mean is the one with the least unnecessary dangers attached.
There are a few general power-progressions you should try to observe:
Those are just a few examples. Being a good engineer doesn't mean being the one who smuggly wields tools of great power, confident you'll not fuck up; Its great when one can do that when they have no other reasonable choice--and you'll still fuck up--but a trait of a good engineers is that they seek out the solutions which are exposed to the minimum set of potential hazards while meeting requirements of (in mungable order) safety, performance, maintainability, usability, and ease of engineering.
Language features are not inherently evil (not even goto), but they are sometimes misapplied and the more commonly misapplied they are, or the worse the repercussions are, the worse their reputation becomes. Sometimes this is exacerbated by the way that languages are taught, as is the case with how inheritance has come to have such a poor reputation. Sometimes its exacerbated by the mistranslation of programming skills from one language to another; in general, a Java programmer (or C# programmer to a somewhat lesser degree) will *way* abuse inheritance if tasked to write C++ (and they'll probably leak memory like a sieve too :) ).
TL;DR; Know thy tools, and program.
