How to Write Unmaintainable Code (1999)
doc.ic.ac.uk
doc.ic.ac.uk
It's actually a good advice. A class not designed to be extendable should be marked as final.
But 1999, that was peak "inheritance is how we fix everything" thinking.
About the only reason to not do this is if you are writing a library. Even then, it's better to make extensions available through things like closures (not really available in 1999).
Properly designing classes for inheritance takes proactive care and is, in my experience, almost never done unless the author has been forced to by external forces (through APIs or agreements with other developers).
I'll see this and raise inherited SAS code where data sets in the process were named "AAA", "BBB", and so on. To prevent any kind of naming reason, even chronological, new data sets could adopt others' when the existing data set would no longer show up in the program. Which was so helpful when updates needed the previous data.
Let's just say that the original programmer had adopted MANY of the techniques in the linked post. The first thing I did was to go through all the code and convert it to only have one statement per line. eye roll
Claude Skill for Java code straight from the essay