final类可以避免在添加新方法时破坏公共API

假设在基类的版本1中:

public class Base {}

客户会这样做:

class Derived extends Base {
    public int method() { return 1; }
}

然后，如果在版本2中，你想添加一个方法method到Base:

class Base {
    public String method() { return null; }
}

这将破坏客户端代码。

如果我们使用final类Base，客户端就不能继承，方法的添加也不会破坏API。

假设你有一个Employee类，它有一个方法greet。当greet方法被调用时，它只是简单地打印Hello everyone!这就是greet方法的预期行为

public class Employee {

    void greet() {
        System.out.println("Hello everyone!");
    }
}

现在，让GrumpyEmployee继承Employee并重写greet方法，如下所示。

public class GrumpyEmployee extends Employee {

    @Override
    void greet() {
        System.out.println("Get lost!");
    }
}

现在在下面的代码中看看sayHello方法。它以Employee实例作为参数，并调用greet方法，希望它会说Hello everyone!但我们得到的是滚开!这种行为变化是因为员工grumpyEmployee = new grumpyEmployee ();

public class TestFinal {
    static Employee grumpyEmployee = new GrumpyEmployee();

    public static void main(String[] args) {
        TestFinal testFinal = new TestFinal();
        testFinal.sayHello(grumpyEmployee);
    }

    private void sayHello(Employee employee) {
        employee.greet(); //Here you would expect a warm greeting, but what you get is "Get lost!"
    }
}

如果Employee类是final类，则可以避免这种情况。想象一下，如果没有将String Class声明为final，厚脸皮的程序员会造成多大的混乱。

其他的答案集中在final类告诉编译器什么:不允许另一个类声明它扩展了这个类，以及为什么这样做是可取的。

但是编译器并不是短语final类的唯一读者。每个读源代码的程序员也会读这个。它可以帮助快速理解程序。

In general, if a programmer sees Thing thing = that.someMethod(...); and the programmer wants to understand the subsequent behaviour of the object accessed through the thing object-reference, the programmer must consider the Thing class hierarchy: potentially many types, scattered over many packages. But if the programmer knows, or reads, final class Thing, they instantly know that they do not need to search for and study so many Java files, because there are no derived classes: they need study only Thing.java and, perhaps, it's base classes.

在一个场景中，final很重要，当您出于安全原因想要防止类的继承时。这允许您确保您正在运行的代码不会被其他人覆盖。

另一个场景是为了优化:我似乎记得Java编译器内联了final类中的一些函数调用。因此，如果你调用a.x()并且a被声明为final，我们在编译时就知道代码将是什么，并且可以内联到调用函数中。我不知道这是否真的做到了，但最终是有可能的。

Be careful when you make a class "final". Because if you want to write an unit test for a final class, you cannot subclass this final class in order to use the dependency-breaking technique "Subclass and Override Method" described in Michael C. Feathers' book "Working Effectively with Legacy Code". In this book, Feathers said, "Seriously, it is easy to believe that sealed and final are a wrong-headed mistake, that they should never have been added to programming languages. But the real fault lies with us. When we depend directly on libraries that are out of our control, we are just asking for trouble."

要解决最后一个类问题:

有两种方法可以让一门课成为期末考试。第一种是在类声明中使用关键字final:

public final class SomeClass {
  //  . . . Class contents
}

使类成为final的第二种方法是将其所有构造函数声明为private:

public class SomeClass {
  public final static SOME_INSTANCE = new SomeClass(5);
  private SomeClass(final int value) {
  }

如果您发现它实际上是final，那么将它标记为final可以省去麻烦，请查看这个Test类。乍一看是公开的。

public class Test{
  private Test(Class beanClass, Class stopClass, int flags)
    throws Exception{
    //  . . . snip . . . 
  }
}

不幸的是，由于类的唯一构造函数是private的，因此不可能扩展这个类。在Test类的情况下，没有理由该类应该是final类。Test类是隐式final类如何导致问题的一个很好的例子。

所以当你隐式地将一个类的构造函数设为private时，你应该将它标记为final。