What are the pros and cons of using final methods (in abstract classes)

extensibilityfinalobject-oriented-design

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.

Somewhat related:

Best Answer

I think the arguments presented in Eric Lippert's blog post from 2004 Why Are So Many Of The Framework Classes Sealed? apply to "final methods" (in the Java sense of that term) as well.

Every time you write a method A (in a framework) which calls a non-final method B, A cannot rely on B on doing what it was originally doing any more, so A has to be designed way more robust than if B was final. For example, the implementation A may have to invest more effort into exception handling (when calling B), the exact behaviour of B and which constraints apply when overriding it has to be documented more precisely, and A must be tested more thoroughly with different overriden variants of B. Moreover, there must be invested more thought into the exact distribution of responsibilites between A and B.

In fact, in an abstract class of a framework, the way overrideable methods are used internally becomes part of the API of that framework (see example in the comments by @wchargin). Once the framework has been published to the world, it becomes significantly harder to change the semantics of those methods.

So this makes it a tradeoff: by making B final, you make it easier to create a correct, tested and reliable implementation of method A, and you make it easier to refactor A and B inside the framework later, but you also make it harder to extend A. And if a framework's implementation guide favors towards making nothing final, I would be highly sceptical about the reliability of that piece of software.

Let me cite Eric's last paragraph, which applies perfectly here:

Obviously there is a tradeoff here. The tradeoff is between letting developers save a little time by allowing them to treat any old object as a property bag on the one hand, and developing a well-designed, OOPtacular, fully-featured, robust, secure, predictable, testable framework in a reasonable amount of time -- and I'm going to lean heavily towards the latter. Because you know what? Those same developers are going to complain bitterly if the framework we give them slows them down because it is half-baked, brittle, insecure, and not fully tested!

This older question (and its top answer) from 2014 may serve as an excellent answer here as well:

Why was C# made with "new" and "virtual+override" keywords unlike Java?

In C#, methods are "final" by default (in the Java meaning of that term), and one has to add the virtual keyword explicitly to make them overrideable. In Java, it is the other way round: every method is "virtual" by default, and one has to mark them as final to prevent this.

The top answer to that former question cites Anders Hejlsberg to explain the different "schools of thought" behind these approaches:

the school of thought he calls "academic" ("Everything should be virtual, because I might want to override it someday."), vs.
the "pragmatic" school of thought ("We've got to be real careful about what we make virtual.")

Let me finally say that the arguments of the latter look more convincing to me, but YMMV.

Related Solutions

SOLID – SOLID Principles vs. Static Methods

What is more important: following the SOLID principles, or having a simpler interface?

Interface vis-a-vis SOLID

These are not mutually exclusive. The interface should express the nature of your business model ideally in business model terms. The SOLID principles is a Koan for maximizing Object Oriented code maintainability (and I mean "maintainability" in the broadest sense). The former supports the use and manipulation of your business model and the latter optimizes code maintenance.

Open/Closed Principle

"don't touch that!" is too simplistic an interpretation. And assuming we mean "the class" is arbitrary, and not necessarily right. Rather, OCP means that you have designed your code such that modifying it's behavior does not (should not) require you to directly modify existing, working code. Further, not touching the code in the first place is the ideal way to preserve the integrity of existing interfaces; this is a significant corollary of OCP in my view.

Finally I see OCP as an indicator of existing design quality. If I find myself cracking open classes (or methods) too often, and/or without really solid (ha, ha) reasons for doing so then this may be telling me I've got some bad design (and/or I don't know how to code OO).

Give it your best shot, we have a team of doctors standing by

If your requirements analysis tells you that you need to express the Product-Review relationship from both perspectives, then do so.

Therefore, Wolfgang, you may have a good reason for modifying those existing classes. Given the new requirements, if a Review is now a fundamental part of a Product, if every extension of Product needs Review, if doing so makes client code appropriately expressive, then integrate it into the Product.

Abstract Classes vs Interfaces – Key Differences and Usage

In layman's terms:

Interfaces are for "can do/can be treated as" type of relationships.

Abstract ( as well as concrete ) classes are for "is a" kind of relationship.

Look at these examples:

class Bird extends Animal implements Flight;
class Plane extends Vehicle implements Flight, AccountableAsset;
class Mosquito extends Animal implements Flight;
class Horse extends Animal;
class RaceHorse extends Horse implements AccountableAsset;
class Pegasus extends Horse implements Flight;

Bird, Mosquito and Horse are Animals. They are related. They inherit common methods from Animal like eat(), metabolize() and reproduce(). Maybe they override these methods, adding a little extra to them, but they take advantage of the default behavior implemented in Animal like metabolizeGlucose().

Plane is not related to Bird, Mosquito or Horse.

Flight is implemented by dissimilar, unrelated classes, like Bird and Plane.

AccountableAsset is also implemented by dissimilar, unrelated classes, like Plane and RaceHorse.

Horse doesn't implement Flight.

As you can see classes (abstract or concrete) helps you build a hierarchies, letting you inhering code from the upper levels to the lower levels of the hierarchy. In theory the lower you are in the hierarchy, the more specialized your behavior is, but you don't have to worry about a lot of things that are already taken care of.

Interfaces, in the other hand, create no hierarchy, but they can help homogenize certain behaviors across hierarchies so you can abstract them from the hierarchy in certain contexts.

For example you can have a program sum the value of a group of AccountableAssets regardless of their being RaceHorses or Planes.

Best Answer

Related Solutions

SOLID – SOLID Principles vs. Static Methods

Abstract Classes vs Interfaces – Key Differences and Usage

Related Topic