小编典典

为什么我不能在 Java 接口中定义静态方法？

all

编辑： 从 Java 8 开始，接口中现在允许使用静态方法。

这是示例：

public interface IXMLizable<T>
{
  static T newInstanceFromXML(Element e);
  Element toXMLElement();
}

这当然行不通。但为什么不呢？

可能的问题之一是，当你打电话时会发生什么：

IXMLizable.newInstanceFromXML(e);

在这种情况下，我认为它应该只调用一个空方法（即{}）。所有子类都将被迫实现静态方法，因此在调用静态方法时它们都可以。那么为什么这不可能呢？

编辑： 我想我正在寻找比“因为 Java 就是这样”更深的答案。

静态方法不能被覆盖是否有特定的技术原因？也就是说，为什么 Java 的设计者决定让实例方法可覆盖而不是静态方法？

编辑： 我的设计问题是我正在尝试使用接口来强制执行编码约定。

也就是说，接口的目标是双重的：

我希望 IXMLizable 接口允许我将实现它的类转换为 XML 元素（使用多态，工作正常）。
如果有人想创建一个实现 IXMLizable 接口的类的新实例，他们总是知道会有一个 newInstanceFromXML(Element e) 静态构造函数。

除了在界面中添加评论之外，还有其他方法可以确保这一点吗？

阅读 171

2022-03-10

共1个答案

小编典典

Java 8 允许静态接口方法

在 Java 8 中，接口可以有静态方法。它们也可以有具体的实例方法，但不能有实例字段。

这里真的有两个问题：

为什么在过去糟糕的日子里，接口不能包含静态方法？
为什么不能覆盖静态方法？

接口中的静态方法

没有强有力的技术原因说明接口在以前的版本中不能有静态方法。重复问题的海报很好地总结了这一点。静态接口方法最初被认为是一个小的语言变化，后来官方提议在
Java 7
中添加它们，但后来由于无法预料的复杂情况而被放弃。

最后，Java 8 引入了静态接口方法，以及具有默认实现的可覆盖实例方法。他们仍然不能有实例字段。这些功能是 lambda
表达式支持的一部分，您可以在JSR 335 的 H 部分中了解更多信息。

覆盖静态方法

第二个问题的答案有点复杂。

静态方法在编译时是可解析的。动态分派对实例方法有意义，其中编译器无法确定对象的具体类型，因此无法解析要调用的方法。但是调用静态方法需要一个类，并且由于该类是
静态已知的——没有编译时间——不需要动态分派。

了解实例方法如何工作的一些背景知识对于理解这里发生的事情是必要的。我确信实际的实现是完全不同的，但是让我解释一下我的方法分派的概念，它可以准确地模拟观察到的行为。

假设每个类都有一个哈希表，该哈希表将方法签名（名称和参数类型）映射到实际的代码块以实现该方法。当虚拟机尝试调用实例上的方法时，它会查询对象的类并在类的表中查找请求的签名。如果找到方法体，则调用它。否则，获取该类的父类，并在那里重复查找。这将继续进行，直到找到该方法，或者没有更多的父类——其结果为NoSuchMethodError.

如果超类和子类的表中都有相同方法签名的条目，则首先遇到子类的版本，并且永远不会使用超类的版本——这是一个“覆盖”。

现在，假设我们跳过对象实例并从子类开始。解决方案可以如上进行，为您提供一种“可覆盖”的静态方法。然而，解析都可以在编译时发生，因为编译器是从一个已知的类开始的，而不是等到运行时为它的类查询一个未指定类型的对象。“覆盖”静态方法没有意义，因为总是可以指定包含所需版本的类。

构造函数“接口”

这里有更多材料来解决最近对该问题的编辑。

听起来您想为IXMLizable. 暂时忘记尝试使用接口强制执行此操作，并假装您有一些满足此要求的类。你会如何使用它？

class Foo implements IXMLizable<Foo> {
  public static Foo newInstanceFromXML(Element e) { ... }
}

Foo obj = Foo.newInstanceFromXML(e);

由于在“构造”新对象时必须显式命名具体类型Foo，编译器可以验证它确实具有必要的工厂方法。如果没有，那又如何？如果我可以实现一个IXMLizable缺少“构造函数”的实例，并且我创建一个实例并将其传递给您的代码，那么它
就是一个IXMLizable具有所有必要接口的实例。

构造是实现的一部分， 而不是接口。任何与接口一起成功工作的代码都不关心构造函数。任何关心构造函数的代码无论如何都需要知道具体类型，接口可以忽略。

2022-03-10