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.

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

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

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.

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.

> 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.

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.

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.