问题标签 [functional-interface]

正如我们所知，在 Java 8 中，引入了函数式接口的概念。功能接口具有一种abstract方法，并且可以使用多种默认或静态方法。

但是为什么一个函数式接口应该只有一个抽象方法呢？如果接口有不止一个抽象方法，为什么这不是功能接口？

我这样做了：

并得到这个例外：

不兼容的类型：Intf 不是功能接口 Intf 接口中的多个非覆盖抽象方法 注意：某些消息已被简化；使用 -Xdiags:verbose 重新编译以获得完整的输出 1 错误

有什么条件不能使用 lambda 替换匿名类吗？

StreamJava 8 中的类定义了一个max需要Comparator参数的方法。这是方法签名：

Comparator是一个功能接口，具有compare带有此签名的抽象方法。通知compare需要 2 个参数。

该Comparable接口有一个compareTo带有此签名的抽象方法。通知compareTo只需要 1 个参数。

在 Java 8 中，以下代码完美运行。但是，我预计会出现编译错误，例如“Integer 类未定义 compareTo(Integer, Integer)”。

有人可以帮助解释为什么可以将实例传递Comparable给期望实例的方法，Comparator即使它们的方法签名不兼容？

学习 Java 8 Lambda，只是想知道编译器如何知道 Comparator 中的哪个方法用于 lambda 表达式？好像不是SAM接口？它有2个抽象方法：

我正在使用 lambda 表达式进行一些测试，但我的代码无法编译。我的 lambda 实现是错误的还是异常处理？以下代码的正确实现是什么？

如果我删除 try catch 块并声明要在方法中抛出的异常，则代码编译并正常运行。

编译错误是：

incompatible types: bad return type in lambda expression

我有一个这样的 Java-8-FunctionalInterface：

Function-Interface 提供了一个-Method compose。我想用它来减少这样的流A：

结果我想要一个函数A，它调用每个AStream 的方法doIt。

但是因为 A不是的实现者Function，所以方法引用Function::compose在那里是不可能的。我不能从Function（或Supplier）扩展，因为那样我将有两个抽象方法（我自己的和一个来自Function）。

我可以做些什么来使我的功能成为可能A？

在 java 8 我有这样的事情：

有没有办法从 implementsB 调用默认功能接口行为，而不必创建匿名内部类并调用它？

这有一个副作用（调用 implementsA 的方法 2 次），需要调用父级的实现，然后让子级的实现能够调用子级的默认实现，以及一些特殊化（如果需要）。如您所见，调用父级的实现非常容易，但是我看不到避免重写默认实现的方法，除非我向实现子接口的类添加一层间接层，并且无法强制执行.

例如，如果 A 解锁或提供对资源的访问权限，例如数据库，而 B 解锁第二个资源（另一个数据库），我认为没有办法让代码解锁 A，然后 B 通过使用功能接口执行此合同，要求A 和 B 被称为。 一层深你可以做到，但 N 层深看起来是不可能的。

我打算使用 lambdas 来避免进行昂贵的调用，而是对我的库用户强制执行操作的语义顺序。

这个问题与“在 Java 中显式调用默认方法”不太一样，因为这个问题是关于 N 级深度的接口，而不仅仅是调用父接口的默认方法。

函数式接口的定义是“函数式接口是只有一个抽象方法（除了 Object 的方法）的接口，因此代表一个单一的函数契约。”

根据这个定义，Comparable<T>绝对是一个函数式接口。

lambda 表达式的定义是“一个 lambda 表达式就像一个方法：它提供了一个形式参数列表和一个主体 - 一个表达式或块 - 用这些参数表示。”

对 lambda 表达式的求值会生成一个功能接口的实例。

因此，lambda 表达式的目的是能够通过实现功能接口的单个​​函数来创建功能接口的实例。IE。允许使用单个函数创建实例。

让我们看一下Comparable<T>，这个界面是为单一功能设计的吗？IE。它是为创建仅具有此单个功能的实例而设计的吗？

的文档Comparable<T>以“此接口对实现它的每个类的对象施加总排序。这种排序称为类的自然排序，类的 compareTo 方法称为其自然比较方法。”

上面这句话清楚地表明，Comparable<T>它并非旨在用作单个函数，而是始终由一个类实现，该类通过添加这个单个函数对其实例具有自然顺序。

这意味着它不是设计为使用 lambda 表达式创建的？

关键是我们不会有任何只是 Comparable 的对象，它旨在被实现并因此用作类的附加功能。

那么，Java 语言中有没有一种方法Comparable<T>可以防止创建 lambda 表达式？接口的设计者是否可以决定该接口是由一个类实现的，而不是通过使用 lambda 表达式使用这个单一方法创建为实例的？

仅仅因为一个接口碰巧有一个抽象方法，它不应该被认为是一个功能接口。

也许，如果 Java 提供了 NotFunctional 之类的注解，编译器可以检查该接口不用于创建 lambda 表达式，例如。

在 Java 8 中，新包java.util.function包含许多函数式接口。该包的文档（http://docs.oracle.com/javase/8/docs/api/java/util/function/package-summary.html）多次引用“函数形状”：

• 有几种基本的函数形状，包括 Function（从 T 到 R 的一元函数）、Consumer（从 T 到 void 的一元函数）、Predicate（从 T 到布尔的一元函数）和 Supplier（从 R 的一元函数）。
• 函数形状具有基于它们最常用的方式的自然属性。基本形状可以通过一个元数前缀来修改，以指示不同的元数，例如 BiFunction（从 T 和 U 到 R 的二元函数）。
• 还有其他派生函数形状可以扩展基本函数形状，包括 UnaryOperator（扩展函数）和 BinaryOperator（扩展 BiFunction）。

我以前从未听说过“函数形状”这个术语，除了上面的文档之外，我几乎无法在任何地方找到对它的引用，但由于那是 Oracle 关于函数接口的正式文档，我想了解它。

任何人都可以提供“功能形状”的定义，并发明一个例子吗？它是计算机科学中的通用术语，还是仅与 Java 8 相关？函数形状与函数描述符（例如Predicate<T> 接口的(T) -> boolean ）有何关系？

更新 Brian Goetz 下面的两条评论回答了我在这篇文章中提出的问题。

我在 Java 8 中有一个功能接口：

主要：

运行这将产生：

这个功能可以吗？是有意的吗？

如果重写将在实现类中完成，并且实现会在某个时候发生变化，那么在调用该方法的每个地方，行为都是相同的，我们将保持一致性。但是，如果我像示例中那样通过 lambda 表达式更改行为/实现，则该行为将仅在下一次更改之前有效，稍后在流程中。这感觉不可靠且难以遵循。

编辑：@assylias 我看不到 someInt() 的行为如何改变......如果我向 someInt 添加一个参数并拥有以下代码怎么办：

var 甚至是最终结果，你将如何用类重写它？