

Inheritance is evil, and must be destroyed: part 1 - danw
http://www.berniecode.com/writing/inheritance/

======
mdemare
The last couple of years my programming style has changed a lot. I've noticed
that I've been using inheritance less and less. When I was still doing Java, I
only used (implementation) inheritance when the API forced me to, and now in
Ruby I hardly use inheritance at all.

I even use objects a lot less - prefering to pass around hashes until they've
blossomed into fairly well defined types. To me, a class is a data structure
that provides a namespace for the functions that manipulate it, and little
more.

In any case, I think nearly empty classes with nothing but accessors have no
use in dynamic languages (in static languages they provide at least code
completion support.)

I also increasingly dislike local variables and if-statements (preferring case
statements). I like my methods having _flow_ , and if-statements and local
variables break that flow, like a caesura in music.

What bothers me is that I don't know if this is my progress towards becoming a
zen-like programmer, or just me being bored with the old way of doing things,
and discovering a new fad. It seems there is no way to tell.

------
cstejerean
one problem that i have with inheritance, especially several layers deep is
that it hides code from the developer and it makes it hard to get an idea of
what is going on. A sequence of calls needs to be traced across several class
definitions. Sometimes inheritance makes sense as an abstraction mechanism but
i think it's often overused, especially in Java

~~~
testapplication
Only a problem if you are browsing your project with notepad.

------
iamwil
The way the author uses the common implementation reminds me of Ruby mixins.
One of the things that takes a bit of getting use to in Ruby is that classes
aren't types, and object hierarchy is used to share implementation, rather
than enforce type.

------
gills
Inheritance is a useful tool. The article mentions the strategy pattern which,
ironically, often requires inheritance to implement. So I feel like the author
may have been burned and/or confused by inheritance, and following true nerd
form has cast it aside completely.

Sometimes when you are using a framework, the productivity gained from
inheritance cannot be ignored. I suppose this depends on the language and
framework design, to a limited extent.

That said, I try to compose rather than inherit when possible, as it provides
a more opaque implementation.

~~~
dangph
> The article mentions the strategy pattern which, ironically, often requires
> inheritance to implement.

Not really. It only requires interface inheritance for statically-typed
languages, which is not really inheritance, and no inheritance at all for
duck-typed languages.

------
jsjenkins168
Compositing should always he used over inheritance where possible, in my
opinion. However, claiming inheritance should never be used is a bit
unrealistic. There are times when it is a useful and logical choice.

------
MuddyMo
Very lucid description of one of the major pitfalls (cough) inherent with a
strict OOP design structure where the problem domain and/or programming
language does not facilitate its imposition.

