问题标签 [default-method]

我正在阅读有关 Java 8 的本教程，作者在其中展示了代码：

然后说

无法从 lambda 表达式中访问默认方法。以下代码无法编译：

但他没有解释为什么这是不可能的。我运行代码，它给出了一个错误，

不兼容的类型：公式不是功能接口`

那么为什么不可能或错误的含义是什么？该接口满足了具有一个抽象方法的功能接口的要求。

书中的问题：

在过去（Java 8 之前），您被告知向接口添加方法是一种不好的形式，因为它会破坏现有代码。现在您被告知可以添加新方法，前提是您还提供了默认实现。

1. 那有多安全？stream描述接口的新方法Collection导致遗留代码编译失败的场景。
2. 二进制兼容性怎么样？JAR 文件中的遗留代码是否仍会运行？”

我的答案如下，但我不太确定。

1. 只有当遗留代码不提供具有相同名称stream和相同签名的方法时（例如，在实现的遗留类中Collection），它才是安全的。否则，这个旧的遗留代码将无法编译。
2. 我认为保留了二进制兼容性，旧 JAR 文件中的遗留代码仍将运行。但我对此完全没有明确的论据。

任何人都可以确认或拒绝这些答案，或者只是为这些答案添加更多的论点、参考或清晰度吗？

在 java 网站的教程页面上的这个例子中。两个接口定义了相同的默认方法startEngine()。一个类实现了这两个接口，并且由于明显的冲突FlyingCar而必须重写。startEngine()

我不明白为什么 from用于指代in和接口FlyingCar的两个版本。据我了解，没有在任何超类中定义，因此不应被称为常驻类。我也没有看到两个接口之间的任何关系superstartEngine()OperateCarFlyCarstartEngine()superFlyingCar

自 Java 8 发布以来，您可以在接口中提供方法的默认实现。

我一直在寻找一种在 UML 中实现这一点的方法，但在这件事上找不到任何东西。接口中默认实现的情况可能太特殊而无法在 UML 规范中采用。

但仍然是问题：

有没有办法在 UML 中显示这些默认方法？

我知道这个问题之前已经被其他人回答过，但答案似乎因情况而异。

我看到很多人说应该实例化该类，以便可以对其进行测试和模拟等...好吧，这是我的代码，在我看来，我可以轻松地对其进行单元测试。

WebsiteLogin.java 是一个扩展 Website.java 的接口，包含一个名为 login() 的 void 方法，它接受三个字符串，用户名、密码和 Url。

AccountLogin.java 是一个扩展 Account 的接口，它包含用于 Username、Password 和 Url 的 getter 方法，以及一个采用布尔值的 setEnabled() 方法。

在一个名为 Login.java 的单独类中，我有一个方法 login()，它采用 WebsiteLogin 和 AccountLogin。该类只有一种方法。

这是代码

所以它登录然后将帐户设置为启用。现在虽然这个方法是静态的，但我仍然可以通过向它发送一个存根 LoginToWebsite 来测试它是否有效。我在这里正确吗？那么不使用静态方法还有其他原因吗？

另一个问题，使用 Java 8 和接口中的默认方法，我可以使用以下内容创建一个名为 Login.java 的接口；

然后在另一个类中实现 Login.java 类并调用

或者这是不好的做法？

学习java 8默认方法。这个链接 像互联网上的任何其他资源一样说

在“最严格的意义上”，默认方法是一个倒退，因为它们允许你用代码“污染”你的接口。但它们提供了允许向后兼容的最优雅和实用的方法。它使 Oracle 可以更轻松地更新所有 Collections 类，并使您可以更轻松地为 Lambda 改造现有代码。

我的理解是 java 8 dev/designers 在接口中提供了默认方法，因此所有实现类都不必不必要地覆盖相同的行为，从而提供向后兼容性。例如：- 如果 ForEach 方法不是默认方法，则每个集合实现类都必须实现它。同意。

为了克服这个问题，我们可以让一个类提供这些默认方法的实现，然后实现像 arraylist 等这样的类可以扩展它。通过这种方式，我们可以同时满足 Java 基础知识，即可重用性和抽象性，即减少接口污染

我确信 java 8 dev/designer 已经考虑过这一点，因为他们学得更多，我在这里遗漏了一些东西。有人可以在这里提供帮助，以便我们的开发人员也可以在这个重大变化中处于领先地位吗？

一个java接口说“TestInterface”有2个方法method1()，method2()由100个不同的类实现。现在我需要引入一个新方法，TestInterface而不需要对已经实现它的其他类进行更改。我如何在java中实现它？

在 Java 8 中，如果我有两个具有不同（但兼容）返回类型的接口，反射会告诉我这两个方法之一是默认方法，即使我实际上没有将该方法声明为默认方法或提供方法体。

例如，采用以下代码片段：

Java 1.8 产生以下输出：

这看起来很奇怪，不仅因为这两种方法都存在，还因为其中一种方法突然莫名其妙地变成了默认方法。

在 Java 7 中运行相同的代码会产生一些意想不到的结果，尽管仍然令人困惑，因为这两种方法具有相同的签名：

Java 肯定不支持多种返回类型，所以这个结果还是很奇怪的。

下一个明显的想法是：“好吧，也许这是一种只适用于接口的特殊行为，因为这些方法没有实现。”

错误的。

产量

这里发生了什么？为什么 Java 将这些作为单独的方法进行枚举，以及其中一种接口方法如何设法成为没有实现的默认方法？

接口延迟需要任何

此接口的实现 [to] 定义一个compareTo方法，该方法提供与其 getDelay 方法一致的排序。

但是我想知道，为什么 Java 8 中没有默认实现，因为compareTo合同要求完全依赖getDelay.

是否有特定原因将其留给实现类？还是在覆盖超级接口时无法创建默认方法？

编辑：为了让我的问题更容易理解，这里有一个例子：

Cloneable在Java中天生就坏了。具体来说，我对接口的最大问题是它需要一个不定义方法本身的方法行为。因此，如果遍历Cloneable列表，则必须使用反射来访问其定义的行为。但是，在 Java 8 中，我们现在有了默认方法，现在我问clone()为什么Cloneable.

我理解为什么接口不能默认 Object 方法，但是，这是一个明确的设计决定，因此可以进行例外处理。

我有点设想弃用Object.clone()并将其内部代码更改为：

并继续使用任何魔法clone()作为Cloneable. 这并不能真正解决clone()仍然很容易错误实施的问题，但这本身就是另一个讨论。

据我所知，这种变化将完全向后兼容：

1. 当前覆盖clone()但未实现的类Cloneable（为什么？！）在技术上仍然可以（即使在功能上是不可能的，但这与以前没有什么不同）。
2. 当前覆盖clone()但确实实现的类Cloneable在其实现中仍将发挥相同的作用。
3. 当前未覆盖clone()但已实现Cloneable（为什么？！）的类现在将遵循规范，即使它在功能上并不完全正确。
4. 那些使用反射和引用的Object.clone()仍然可以正常工作。
5. super.clone()即使引用Object.clone().

更不用说这将解决一个巨大的问题Cloneable。虽然繁琐并且仍然很容易错误地实现，但它可以解决接口的一个巨大的面向对象问题。

我能看到的唯一问题是那些实现Cloneable没有义务覆盖的问题clone()，但这与以前没有什么不同。

有没有内部讨论过，但从未实现？如果是这样，为什么？如果是因为接口不能默认 Object 方法，那么在这种情况下创建异常是否有意义，因为所有继承的对象Cloneable都在期待clone()？