When did people favor composition over inheritance?

> It can easily become a pinball of calls around the hierarchy.

This is why hierarchies should have limited depth. I'd argue some amount of "co-recursion" is to be expected: after all the point of the child class is to reuse logic of the parent but to overwrite some logic.

But if the lineage goes too deep, it becomes hard to follow.

> every time you modify a class, you must review the inner implementation of all other classes in the hierarchy, and call paths to ensure your change is safe.

I'd say this is a fact of life for all pieces of code which are reused more than once. This is another reason why low coupling high cohesion is so important: if the parent method does one thing and does it well, when it needs to be changed, it probably needs to be changed for all child classes. If not, then the question arises why they're all using that same piece of code, and if this refactor shouldn't include breaking that apart into separate methods.

This problem also becomes less pressing if the test pyramid is followed properly, because that parent method should be tested in the integration tests too.

When they find inheritance is actually worse at describe the concept though. With composition you no longer need to implement whatever interface and bridge the implementation by proxy or whatever. You are also not limited to what parent class have (while you can still add all components that parent have to children if you need). Interface and proxy is just composition but worse in my opinion

It depends though. Learning what things don't actually work like the textbooks says is the key to level from junior to senior. Some people never get it, some got it quickly.

Grepping "extends" over a new codebase is a quick way to see how fucked you are when joining a new project/team.

Exactly. Inheritance and composition are two different axises of the implementation reuse problem, just as object-oriented programming and functional programming are two different axises of the expression problem. In both cases, you should want to have both axises available, because they do different things. I think saying "prefer composition over inheritance" makes about as much sense as "prefer the Y-axis over the X-axis in a graphics system": it's a statement that doesn't make sense on its own; it only makes sense in specific scenarios, like "... when making a document scroll".

I think the biggest "mistake" in object-oriented programming is the explanations by analogy that many people advocate. A lot of times, people attempt to use a taxonomic metaphor like the tree of life—"a dog is-a mammal" sort of stuff. As a model it falls apart because even the real world tree of life is a flawed model that doesn't fully capture the complexity of life in the way most lay people assume it does. Try getting a random person to justify a platypus being a mammal. Without specific training in biology they stumble. And most computer scientists attempting to employ this analogy are definitely broadly ignorant about biology. You can see it because a lot of the examples people employ aren't even consistent with the metaphor. You're just as likely to see people say things like, "A dog is-a four-legged animal". I think it's an extremely harmful didactic path down which to start.

A lot of these problems happen because most people don't have a good handle on graph theory. They don't understand when they are trying to force a graph with cycles into a tree. Trees are easy for people to understand and handle, graphs with their pesky cycles are much harder, so I get the appeal. But what people come to call "tech debt" or "degenerate edge cases" are really evidence that an inappropriate model was employed early in development.

In real world examples, you'll see object oriented programming and functional programming as well as inheritance and composition used extensively and successfully. I think GUI libraries are a good example here. Buttons and text boxes both inherit from a control base class. This pattern is pervasive and long standing. But you naturally shouldn't usually[1] try to make a form inherit from control as they are much more appropriately compositions of controls.

[1] I say "shouldn't usually" here because some common subforms can be useful encapsulated as a control for composition into other forms, e.g. an address entry form embedded into a user profile form.