It's my impression -- I've heard it from so many programmers that I respect.

The impression may be biased by my own frustrations dealing with bad abstractions (like: 90% of the classes I've seen out there are semantically broken, a.k.a not state machines).

(To back that up, there is a python script of mine which I think is rather clean. It has basically a single class in it, which was needed because the API of cmd.Cmd relies on inheritance. I had to spend quite some time to circumvent that insane amount of brokenness. I've put in a few cynic comments out of frustration. If you're interested: https://github.com/jstimpfle/gitadmin/blob/08a2c0b7dd1a8950e... Good times.)

Name the use cases where you think inheritance is a good fit.

Inheritance got a bad rap in part because object oriented analysis was done as an exercise in taxonomy (Employee is a Person is a Mammal is an Organism...), instead of identifying useful abstractions. A second problem is using inheritance when composition is obviously better. java.util.Stack is a lovely example of both sins in action.

Where inheritance shines is in enabling close coupling across module boundaries. An example is event routing: how do you enable customization of how events flow through your app? UIKit handles this through inheritance. The base method gives you the default behavior, which you can override to customize. You can stop propagation by just not calling super, or redirect the event by calling the method somewhere else, etc. It's flexible.

JavaScript handles this clumsily, by trying to anticipate all the customizations you might want to do and providing APIs for each of them (event.preventDefault, event.stopPropagation...) Despite all that, frameworks like React have to reimplement event dispatch, because the default behavior is too inflexible.

Here inheritance is the glue that enabled close coupling between UIKit's default event dispatch algorithm and outside modifications to it.

Yeah widget toolkits (if not done across maintenance boundaries) are really the one situation which is always described as a good fit for inheritance. However I don't think I like the idea of "close coupling across module boundaries". Sounds like an antithesis to sustainable architecture to me. Anyway I don't do UI...

It's just a tool. OOP is basically the same as

  Classname_method(&structure, ...)

Inheritance is a good fit when you want execution efficiency when implementing interfaces. It makes you think in terms of base behavior vs customization and thereby re-use code properly. Most of the time, the resul is that the base class implementation is generic enough to do what you need regardless of the specific instance. But if you really need to override base behavior, that's when you can have things layered on top of basic inheritance.

For example:

* Database access (ORM or NoSql)

* Any sort of server object access (eg File, Request, Socket)

* APIs that discourage duck typing to increase cohesion

* Low level implementations that need efficient implementations of function calls

* Automatic, zero-overhead memory management http://www.stroustrup.com/resource-model.pdf

Duh. that paper is... long. And it mentions inheritance 0 times.

Maybe compared to duck typing inheritance increases cohesion. But classes in practice most often discourage cohesion. That's why they came up with Aspect-oriented programming. Not that that is practical, but it comes from the insight that organisation as stateful objects naturally leads to coupling, since you must lump most functionality into one mostly closed concept. And the odds are your next class will have a very similar structure regarding dependencies and implementation. And then you end up with inheritance just to share code, and end up with these totally meaningless ball-of-mud inheritance structures.

> Low level implementations that need efficient implementations of function calls

I'm pretty sure the most efficient "implementation" of function calls are still function calls.

I meant method calls

Are those programmers Java or C# programmers?

I'm not an OOP expert, but I get the impression that type classes are similar to interfaces in Java and C#, which are used all the time in those languages. If you told a C# programmer that IEnumerable was an example of bad architecture, I think you may get a somewhat different response.

Agreed. I didn't claim that interfaces were bad architecture (but actually I've often seen it overdone).

A drawback of inheritance is strong coupling.