Why would you make a whole class sealed/final?

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开发者_如何学C 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?

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.

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.

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.

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.

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'.

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.