问题标签 [default-method]

Java 8 引入了默认方法来提供扩展接口的能力，而无需修改现有实现。

我想知道当该方法已被覆盖或由于不同接口中的默认实现冲突而不可用时，是否可以显式调用该方法的默认实现。

考虑到上面的代码，你将如何A.foo()从 B 类的方法中调用？

Java 8 包含一个名为Defender 方法的新功能，它允许在接口中创建默认方法实现。

首先，对于所有 Java 精简程序员来说，这是一个巨大的范式转变。我查看了 Brian Goetz 提供的 JavaOne 13 演示文稿，他在其中讨论了 Collections 库中的新功能stream()和parallelStream()实现。

对于在Collection接口中添加新方法，他们不可能只是添加一个新方法而不破坏以前的版本。所以他告诉我们，为了迎合这一点，添加了默认方法的新功能。

现在我的问题基本上是默认方法在需要向接口添加新方法而不破坏客户端代码时才有用？或者它还有其他用途吗？

Java 8 允许在称为Default Methods的接口中默认实现方法。

我对何时使用那种interface default method, 而不是abstract class(with abstract method(s)) 感到困惑。

那么什么时候应该使用带有默认方法的接口，什么时候应该使用抽象类（带有抽象方法）？抽象类在那种情况下仍然有用吗？

Java 8 接口默认方法与抽象类中的非抽象方法 - 两者之间是否有任何差异（除了 iface 的差异 - 类、可见性等）

默认方法不是 Java 的退步，意味着它违背了 Java 多年来一直宣传的本质吗？！

我在需要同步的接口中有许多默认方法，似乎只有这些this方法可用：

问题是，我想在私有锁上同步，而不是this为了更好地控制：

解决方案？聪明的解决方法？或者只是忍受它:)！

Minimum complete definition of Collection interface consists only of two methods: iterator() and size(), which are abstract in AbstractCollection.

Why all other methods not made default in Java 8? Compatibility shouldn't be an issue, for example, Iterator.remove() was abstract until Java 7, but made default since Java 8.

Subclassing from AbstractCollection is inconvenient sometimes, when I want a Collection implementation to be a member of another class hierarchy. Wasn't that one of the reasons why default methods in interfaces actually needed in Java?

The same question about Map, List and other basic interfaces, comprising Java Collection Framework.

UPDATE

Paul Sandoz:

Generally we have only converted existing abstract methods on an interface to non-abstract if there was a compelling reason to aid implementations, such as Iterator.remove.

These are not new methods on Collection, and there are already implementations in AbstractCollection. The advantage of converting these abstract into non-abstract methods its not particularly compelling given one is most likely to inherit from AbstractCollection or provide more efficient implementations.

It would be possible to move all non-abstract methods on AbstractCollection to Collection. If we were starting from a blank sheet of paper that is what we might have done. (Note one cannot do this with all non-abstract methods on AbstractList.)

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/025118.html

我对 Java 8 中的“新”接口有一些疑问，我有以下代码：

（许多的一种实现）

问题：

1. 从 OOP 的角度来看，接口的实现是否正确，尤其是考虑到我通过公共 getter 来“存储/访问数据”这一事实。
2. 考虑到最基本的Drawable不会被实例化，也不会被镶嵌，所以在伪代码isTessellated() = false中，isInstanced() = false声明getInstancesCount() = 0具有这些属性的默认方法是否有效？

我经常想将一个列表映射到另一个列表。例如，如果我有一个人员列表，并且我想要他们的姓名列表，我想做：

目标

Java 8 可以做到这样的事情：

JAVA 8 版本

但这显然不是那么好。事实上，我认为使用 Guava 更清洁：

番石榴版

但是，我确实喜欢链接。那么，我的目标可能吗？

我听说有人说 Java 8 默认方法类似于 C# 扩展方法。使用 C# 扩展方法，我可以轻松地将辅助方法添加到IEnumerable<T>：

但是我不知道如何使用默认方法来扩展现有接口。

此外，这显然是一个微不足道的例子。一般来说，我希望能够扩展List<T>和Iterable<T>接口以使与流 api 的交互更容易。

访问者模式（双重分派）就其本身而言是一种非常有用的模式，但如果将任何新成员添加到继承层次结构中，它经常被仔细检查是否会破坏接口，这是一个有效的观点。

但是在 Java 8 中引入了默认方法之后，现在我们可以在接口中定义默认实现，客户端接口不会中断，客户端可以适当地优雅地采用更改后的接口。

NewType如果将来引入新类型，现在使用默认方法不再破坏客户端代码。

这是否使访客更易于采用和有用？

我有一个接口，我想在其中提供一个默认方法来序列化继承的类。我使用一个JsonSerializer<T>类来进行序列化。

该方法如下所示：

所以我在实例化AX的时候，想用write方法来序列化AX

我需要将 AX 的类型传递给 A 中的 write 方法。这可能吗？