Java方法关键字“final”及其用途

Question

当我创建复杂类型层次结构（多个级别，每个级别多个类型）时，我喜欢在实现某些接口声明的方法上使用 final 关键字。一个例子：

interface Garble {
  int zork();
}

interface Gnarf extends Garble {
  /**
   * This is the same as calling {@link #zblah(0)}
   */
  int zblah();
  int zblah(int defaultZblah);
}

然后

abstract class AbstractGarble implements Garble {
  @Override
  public final int zork() { ... }
}

abstract class AbstractGnarf extends AbstractGarble implements Gnarf {
  // Here I absolutely want to fix the default behaviour of zblah
  // No Gnarf shouldn't be allowed to set 1 as the default, for instance
  @Override
  public final int zblah() { 
    return zblah(0);
  }

  // This method is not implemented here, but in a subclass
  @Override
  public abstract int zblah(int defaultZblah);
}

我这样做有几个原因：

1. 它帮助我开发类型层次结构。当我向层次结构添加一个类时，非常清楚我必须实现哪些方法，以及我不能重写哪些方法（以防我忘记有关层次结构的详细信息）
2. 我认为重写具体根据设计原则和模式，例如模板方法模式，东西是不好的。我不希望其他开发人员或我的用户这样做。

所以 final 关键字非常适合我。我的问题是：

为什么它在野外很少被使用？你能给我展示一些 final （与我的情况类似）会非常糟糕的例子/原因吗？

Answer 1

为什么它在野外很少被使用？

因为你应该多写一个词来使变量/方法成为最终的

您能否向我展示一些最终（与我的情况类似）非常糟糕的示例/原因？

通常我会在 3D 零件库中看到此类示例。在某些情况下，我想扩展一些类并改变一些行为。尤其是在没有接口/实现分离的非开源库中，这是危险的。

Answer 2

当我编写抽象类并希望明确哪些方法是固定的时，我总是使用final。我认为这是this关键字最重要的功能。

但是，当你不希望课程延长时，为什么要大惊小怪呢？当然，如果您正在为其他人编写库，您会尽力保护它，但是当您编写“最终用户代码”时，在某种程度上，尝试使您的代码万无一失只会导致惹恼维护开发人员，他们会试图找出如何绕过您建造的迷宫。

将课程定为期末也是如此。尽管某些类本质上应该是最终类，但目光短浅的开发人员常常会简单地将继承树中的所有叶类标记为final。

毕竟，编码有两个不同的目的：向计算机发出指令以及将信息传递给阅读代码的其他开发人员。第二个大多数时候都会被忽略，尽管它几乎与让代码正常工作一样重要。放入不必要的 final 关键字就是一个很好的例子：它不会改变代码的行为方式，因此其唯一目的应该是通信。但你们交流什么呢？如果您将一个方法标记为final，维护者会认为您已经充分阅读了这样做的信息。如果事实证明你没有这样做，那么你所做的只是让别人感到困惑。

我的方法是（显然我在这里可能完全错误）：不要写下任何内容，除非它改变了代码的工作方式或传达有用的信息。

Answer 3

为什么它在野外很少被使用？

这与我的经历不符。我发现它在各种图书馆中使用得非常频繁。仅举一个（随机）示例：查看

http://code.google 中的抽象类。 com/p/guava-libraries/

，例如 com.google.common.collect.AbstractIterator。 peek()、hasNext()、next() 和 endOfData() 是最终版本，仅留下 computeNext() 给实现者。在我看来，这是一个非常常见的例子。

反对使用 final 的主要原因是允许实现者更改算法 - 您提到了“模板方法”模式：修改模板方法或通过一些预定义来增强它仍然有意义。 /post 操作（不会用数十个前/后钩子向整个班级发送垃圾邮件）。

pro 使用 final 的主要原因是为了避免意外的实现错误，或者当该方法依赖于未指定的类的内部（因此将来可能会发生变化）时。

Answer 4

我认为它不常用的原因有两个：

1. 人们不知道它的存在
2. 人们在构建方法时没有考虑它的习惯。

我通常属于第二个原因。我确实在一些通用的基础上重写了具体的方法。在某些情况下，这很糟糕，但很多时候它并不与设计原则相冲突，事实上可能是最好的解决方案。因此，当我实现一个接口时，我通常不会对每个方法进行足够深入的思考来决定最终关键字是否有用。特别是因为我从事许多经常变化的业务应用程序。

Answer 5

为什么它在野外很少被使用？

因为它不应该是必要的。它也不会完全关闭实现，因此实际上它可能会给您一种错误的安全感。

由于里氏替换原则，这应该是不必要的。该方法有一个契约，并且在正确设计的继承图中，该契约已得到满足（否则它是一个错误）。示例：

interface Animal {
    void bark();
}

abstract class AbstractAnimal implements Animal{
   final void bark() {
       playSound("whoof.wav"); // you were thinking about a dog, weren't you?
   }
}

class Dog extends AbstractAnimal {
  // ok
}

class Cat extends AbstractAnimal() {
  // oops - no barking allowed!
}

如果不允许子类（为其）做正确的事情，您可能会引入错误。或者，您可能需要其他开发人员将您的 Garble 接口的继承树放在您的接口旁边，因为您的最终方法不允许它执行其应该执行的操作。

错误的安全感是非静态最终方法的典型特征。静态方法不应该使用实例中的状态（它不能）。非静态方法可能可以。您的最终（非静态）方法可能也会这样做，但它不拥有实例变量 - 它们可能与预期不同。因此，您给继承 AbstractGarble 形式的类的开发人员增加了负担 - 确保实例字段在任何时间点都处于您的实现所期望的状态。在调用您的方法之前，没有为开发人员提供一种准备状态的方法，如下所示：

int zblah() {
    prepareState();
    return super.zblah();
}

在我看来，除非您有充分的理由，否则您不应该以这种方式关闭实现。如果您记录了您的方法契约并提供了 junit 测试，您应该能够信任其他开发人员。使用 Junit 测试，他们实际上可以验证里氏替换原则。

附带说明一下，我偶尔会关闭一个方法。特别是当它位于框架的边界部分时。我的方法做了一些簿记，然后继续到由其他人实现的抽象方法：

final boolean login() {
    bookkeeping();
    return doLogin();
}
abstract boolean doLogin();

这样就没有人忘记做簿记，但他们可以提供自定义登录。您是否喜欢这样的设置当然取决于您:)