In the Java, C++, and C# worlds, there’s this idea that the appropriate way to perform code reuse is through inheritance — even though idiomatic code structuring in these languages typically makes inherited methods nearly totally useless. Normally, any inherited method either needs to be rewritten or is structured in such a way that it provides next to no functionality.

This is particularly bad in Java, where multiple inheritance isn’t possible.

Ultimately, this problem is a side effect of several language decisions interacting: these languages have explicit static nominal types (in other words: the type name & its place in the inheritance hierarchy is how the type checker thinks about the type, rather than its members, and this type information is attached to the object in memory at compile time and must be specified by the programmer in the source code), and class construction is a compile time rather than runtime process.

In other words, you’re limited to using types that are explicit children of whatever type name you associate with a variable, you can’t let the compiler choose the appropriate type, and you can’t quickly make a new type out of some combination of old types for a one-off change. This confluence of situations means that inheritance is necessary (or else your code won’t compile) but too inflexible to be convenient. (And in Java it gets worse: because of single inheritance, ultimately, everybody just ends up using interfaces instead of superclasses, which don’t provide any code reuse at all and merely act as a poor simulation of structural typing in a nominal-typing context.)

These problems are compounded in practice in industry, where there’s a lot of java code being written by kids just out of college (where they spent four years getting told that inheritance is the best way to do code reuse & abstraction layers have no downsides, while they worked on nothing but toy problems).