For the purpose of writing a coding styleguide, how should final methods in software design be judged?
By final I mean the Object-oriented sense that a class that can be subclassed provides methods, and that class using special syntax to prevent subclasses from modifying certain methods.
In languages like Java, there are other ways to prevent modifications of behavior, such as making methods final, or using static methods (where applicable).
As an example, this styleguide has a section "No final methods or classes" https://doc.nuxeo.com/corg/java-code-style/
No Final Methods or Classes
This hinders reusability. Nuxeo is a platform and we never know when it'll be useful to subclass something.
No private or Package-Private Methods or Fields.
This hinders reusability, for the same reason as above.
On the other hand Guava has classes with final methods, like https://guava.dev/releases/19.0/api/docs/com/google/common/collect/AbstractIterator.html
The JDK (Java) has some classes with very few final methods, like ArrayList, AbstractList, some with several final methods like HashMap, and some with many final methods, like AbstractPipeline.
Some people will say this relates to the Open-closed principle (Clarify the Open/Closed Principle), but articles on that topic usually do not talk about final methods.
Another angle is that this is related to the composition over inheritance design debate (Why should I prefer composition over inheritance?), since the idea may be to provide functionality via inheritance when considering whether to make methods final.
- In C++, when should I use final in virtual method declaration?
- Object oriented immutability: final classes or final methods