[smarks]

The author is onto something but I’m afraid it’s not explained very well. I think he’s mostly right though.

While reading it I was reminded of a design/implementation style I’ve run across several times over the years which is to find an existing class that does something similar to what you want. Then, subclass it and override methods until you get the behavior you want. And you’re done!

This leads directly to the Fragile Base Class problem. I think it also violates the Open/Closed principle. When subclassing occurs across components that are released independently (e.g., a library and an application), it either leads to continual breakage at each release, or ossification of the library. The latter happened to Java’s Swing. It got to the point where it was difficult to fix any bugs, because any “fix” would end up breaking some subclass that relied on the old behavior.

(See also Hyrum’s Law, which is more general than subclassing & inheritance.)

[kaba0]

I have to agree with you. On the other hand, closed hierarchies can be an elegant solution to certain problems. Eg. sealed classes (and basically their single-class counterparts, final classes) avoid the mentioned problems in Java’s parlance.

One exception comes to mind though — Java’s SAMs, or in the general case, classes that more or less only wrap around a few methods intended to be overridden/implemented with clear requirements (but maybe this use case also should be restricted to interfaces?) But the default should be to add an explicit open instead of defaulting to non-final.