当我们已经有了抽象类时，为什么要将默认方法和静态方法添加到Java 8的接口中？

#1 楼

Java标准库中有一个很好的激励默认方法的示例，您现在在其中有了

list.sort(ordering);

而不是

Collections.sort(list, ordering);

如果没有多个相同的List.sort实现，我认为他们不可能做到这一点。

#2 楼

实际上，正确的答案是在Java文档中找到的，其中指出：

[d]错误方法使您可以向库的接口添加新功能，并确保与为较早版本编写的代码二进制兼容这些接口。

这一直是Java痛苦的根源，因为一旦接口公开，它们往往就不可能发展。 （文档中的内容与您在注释中链接到的文章有关：通过虚拟扩展方法进行接口演化。）此外，只有通过扩展以下功能才能快速采用新功能（例如lambda和新的流API）。现有集合接口并提供默认实现。破坏二进制兼容性或引入新的API意味着将需要数年时间才能正式使用Java 8的最重要功能。
文档中再次揭示了允许在接口中使用静态方法的原因：[t]您可以更轻松地在库中组织帮助程序方法；您可以将特定于接口的静态方法保留在同一接口中，而不是在单独的类中。换句话说，现在可以（最终）将像java.util.Collections这样的静态实用程序类看作是一般的反模式（当然并不总是）。我的猜测是，一旦实现了虚拟扩展方法，对这种行为的支持就变得微不足道了，否则可能无法完成。
类似地，这些新功能如何受益的一个例子是考虑一个最近让我烦恼的类java.util.UUID。它实际上并没有提供对UUID类型1、2或5的支持，因此也不能轻易对其进行修改。它也被预定义的随机生成器所束缚，不能被覆盖。为不受支持的UUID类型实现代码需要直接依赖于第三方API而不是接口，或者维护转换代码以及随之而来的额外垃圾收集成本。使用静态方法，可以将UUID定义为接口，从而允许缺失部分的真正第三方实现。 （如果最初将UUID定义为接口，那么我们可能会有一些笨拙的带有静态方法的UuidUtil类，这也很糟糕。）许多Java核心API由于无法基于接口而退化，但自Java 8幸好，这种不良行为的借口数量有所减少。字段），而接口则不能。因此，它不等同于多重继承，甚至不等同于混合类型继承。适当的mixin（例如Groovy 2.3的特征）可以访问状态。 （Groovy还支持静态扩展方法。）
在我看来，遵循Doval的榜样也不是一个好主意。一个接口应该定义一个合同，但是不应该强制执行该合同。 （无论如何都不是Java。）正确验证实现是测试套件或其他工具的责任。可以通过注释来定义合同，而OVal是一个很好的例子，但是我不知道它是否支持在接口上定义的约束。即使目前尚不存在这样的系统，也是可行的。 （策略包括通过注释处理器API编译javac的编译时自定义和运行时字节码的生成。）理想情况下，合同应在编译时执行，在最坏的情况下使用测试套件执行，但我的理解是运行时执行是皱眉。另一个可能有助于Java合同编程的有趣工具是Checker Framework。

#3 楼

因为您只能继承一个类。如果您有两个接口，其实现足够复杂以至于需要一个抽象基类，那么这两个接口在实践中是互斥的。静态方法并将所有字段转换为参数。这将允许该接口的任何实现者调用静态方法并获得功能，但是用一种已经太冗长的语言来说，这是一个很大的样板。


关于为什么能够在接口中提供实现的有用性，请考虑以下Stack接口：

如果堆栈为空，则为异常。我们可以通过将pop分为两种方法来强制执行此规则：执行合同的pop方法和执行实际弹出操作的public final方法。

public interface Stack<T> {
    boolean isEmpty();

    T pop() throws EmptyException;
 }

确保所有实现都遵守合同，我们还使他们不必检查堆栈是否为空并引发异常。这是一个巨大的胜利！...除了必须将接口更改为抽象类这一事实。在具有单一继承的语言中，这会大大降低灵活性。它使您可能的接口互斥。能够提供仅依赖于接口方法本身的实现将解决该问题。

我不确定Java 8向接口添加方法的方法是否允许添加最终方法或受保护的抽象方法，但是我知道D语言允许这样做，并为合同设计提供本地支持。由于protected abstract是最终的，因此此技术没有危险，因此没有实现类可以覆盖它。

对于可覆盖方法的默认实现，我假设添加到Java API的任何默认实现都仅依赖于它们添加到的接口的协定，因此，正确实现该接口的任何类也将在默认实现下正确地运行。 />
此外，


接口和抽象类之间几乎没有区别（除了多重继承）。实际上，您可以使用接口模拟常规类。


由于您无法在接口中声明字段，因此情况并非如此。您在接口中编写的任何方法都不能依赖任何实现细节。


作为支持接口中静态方法的示例，请考虑Java API中的工具类（如Collections）。该类仅存在是因为这些静态方法无法在其各自的接口中声明。同样可以在pop接口中声明Collections.unmodifiableList，这样会更容易找到。

#4 楼

也许目的是通过取代通过依赖项注入静态信息或功能的需求，从而提供创建混合类的能力。接口功能。

#5 楼

我在default方法中看到的两个主要目的（某些用例可同时满足两个目的）：


语法糖。实用程序类可以达到这个目的，但是实例方法更好。
现有接口的扩展。该实现是通用的，但有时效率很低。

如果只是第二个目的，您将不会在Predicate这样的全新界面中看到它。所有带有@FunctionalInterface的带注释的接口都必须具有精确的一种抽象方法，以便lambda可以实现它。添加的default方法（例如and，or，negate）只是实用程序，您不应覆盖它们。但是，有时静态方法会更好。

对于现有接口的扩展-甚至在那里，一些新方法也只是语法糖。 Collection的方法，例如stream，forEach，removeIf-基本上，这只是实用程序，您无需重写。
然后有类似spliterator的方法。默认实现不是最优的，但是，至少代码可以编译。仅当您的接口已经发布并得到广泛使用时，才诉诸于此。



对于static方法，我想其他方法可以很好地覆盖它：它允许接口成为自己的实用程序类。也许我们可以在Java的未来中摆脱Collections？ Set.empty()会晃动。