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

Question

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

例子如下：

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

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

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

IXMLizable.newInstanceFromXML(e);

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

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

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

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

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

1. 我希望IXMLizable接口允许我将实现它的类转换为XML元素（使用多态性，效果很好）。

2. 如果有人想创建实现IXMLizable接口的类的新实例，他们将始终知道将有一个newInstanceFromXML（Element e）静态构造函数。

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

Answer 1

Java 8允许使用静态接口方法

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

这里确实有两个问题：

1. 为什么在糟糕的过去，接口不能包含静态方法？
2. 为什么不能覆盖静态方法？

接口中的静态方法

没有任何强大的技术原因可以使接口在以前的版本中不能具有静态方法。一个重复问题的发贴人很好地总结了这一点。静态接口方法最初被认为是一种小的语言更改，然后正式提议在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与所有必要的接口。

构造是实现的一部分，而不是接口。任何与接口成功工作的代码都不关心构造函数。任何关心构造函数的代码都必须知道具体类型，并且可以忽略该接口。