Why would you make a whole class sealed/final?

Question

I understand the motivation for making individual methods of a class sealed/final, but what purpose does completely prohibiting inheritance from the class serve? While allowing overriding of certain methods can cause bad things to happen, I can't see how allowing inheritance from your class purely to add behavior to it without overriding existing behavior could ever be a bad thing. If you really want to disallow overriding anything in your class, why not just make every method final but still allow inheritance for the purpose of adding behavior?

Janaye

In the case of java.util.UUID I find the inability to subclass frustrating. – Knudsen

Answer 1

An organisation/software dev team might want to enforce certain coding standards. For example, in order to improve readability, they might only want attribute X of class Y to be modified with method Z and nothing else. If the class were not final, some developer might extend class Y and add method W, which could modify X in a different way and cause confusion and delay when it came to comprehending the code written.

Trip

Isn't making attribute X private the same thing? – Oldfashioned

@Oldfashioned Even with X private, maybe it's desired that only a direct call to Z on a Y object affects X. If a class W overrides Z, then you may be able to alter X through a call to Z on a W object, which breaks the initial desire to change X only through a Z method call directly off a Y object. I personally never seen such situation, but I guess it can happen. – Eleni

Answer 2

There are some good discussions about this in the "Why String is final in Java" question: Why is String class declared final in Java?

The basic summary in that case is, String is immutable, and if it could be subclassed, the subclass might make it mutable.

Kelso

Answer 3

More generally, a class can be made final in order to preserve the invariants that make it work. I highly recommend Joshua Bloch's "Effective Java" for an excellent discussion on this and related issues.

Handspike

Answer 4

Think about it this way: You spent your last 3 months working on a base class for your own framework that others are going to use, and the whole consistency of the framework is based on the code written in this class, modifying this class may cause bugs, errors, and misbehavior of your framework, how do you prevent your great programmers from extending it and override one of its methods?

In addition to this there are class that are supposed to be immutable, such as the java.lang.String class in Java, extending it and changing its behavior could make a big mess!

Finally sometimes setting a class or method as final will increase performance, but I never tested it, and don't see any reason on earth to make a class/method final for a very very tiny performance gain that is equal to zero compared to the time needed to do other stuff in the program.

Flessel

1. The question is about allowing subclassing to add behavior. I understand why you would want to prohibit overriding. 2. If a class takes you 3 months to write, it probably does way too much. – Janaye

Don't take 3 months literarily, the idea was an important class, in a fragile context, and where every other class expects that it will obey a certain behavior. – Flessel

Answer 5

I think it depends.

If I have an internal application I wouldn't use the final on class level by default. Code just gets too cluttered. In some circumstances final modifier is even really annoying, if I want to refactor safely (see the programming by difference term). In some cases the 'default-final-mania' made big problems when I tried to refactor.

On the other hand if I design an api/framework where code is more extension-driven I would use final for classes 'more aggressively'. Here wrong extension can be a big problem and the 'final' modifier is a safe way to avoid such programming mistakes.

But I am just opposed to say use 'final' by default like many do. It has often more drawbacks as advantages. To me defaults should be 'sensible and more common setting'.

Arsenide

Answer 6

This may be a very specific class that should not be extended. By marking a class final, you have just avoided that class to have subclasses and this idea seems against OOP. But, of course according to your requirements & design, there may be classes that should not be extended. So, use final in this cases.

As you may permit classes to extend the sealed class, it is like an exception management of final and somehow you permit inheritance with this functionality. But, again like final, this class should be very specific in the design.

Reserpine