将一个类保留为最终类的一个好处是:-

String类保持为final，这样任何人都不能重写其方法并更改功能。例如，没有人可以改变length()方法的功能。它总是返回一个字符串的长度。

这个类的开发人员不希望任何人改变这个类的功能，所以他把它作为最终的。

面向对象不是关于继承，而是关于封装。继承会破坏封装。

在很多情况下，声明类final是非常有意义的。任何代表“价值”的对象，如颜色或金额，都可能是最终的。他们是独立的。

如果您正在编写类库，请将类设为final，除非您显式地将它们缩进以派生。否则，人们可能会派生你的类并重写方法，破坏你的假设/不变量。这也可能有安全隐患。

Joshua Bloch在《Effective Java》一书中建议明确地为继承而设计，或者禁止为继承而设计，他指出为继承而设计并不是那么容易。

Final类不能扩展。因此，如果你想要一个类以某种方式运行，并且不希望有人重写方法(可能效率较低，恶意代码更多)，你可以将整个类声明为final或你不想被更改的特定方法。

由于声明一个类并不会阻止一个类被实例化，这并不意味着它会阻止类具有对象的特征。只是您必须坚持使用类中声明方法的方式。

假设你有一个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。

我应该指出，没有什么可以阻止您继承一个“应该标记为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."