Lambda表达式与方法引用

Question

IntelliJ一直建议我用方法引用替换我的lambda表达式。

两者之间有什么客观差异吗？

Answer 1

作为用户stuchl4n3k写在评论质疑可能会发生异常。

让我们考虑一些变量field是未初始化的字段，然后：

field = null;
runThisLater(()->field.method());
field = new SomeObject();

不会崩溃，而

field = null;
runThisLater(field::method);
field = new SomeObject();

java会崩溃。lang.NullPointerException：尝试调用虚拟方法“java”。lang.Class java。朗，反对。getClass（），在方法引用语句行，至少在Android上是这样。

今天IntelliJ指出"可能会改变语义学"，同时建议进行这种重构。

这种情况发生在“引用”特定对象的实例方法时。为什么？让我们检查15.13.3的前两段。方法引用的运行时评估：

在运行时，方法引用表达式的求值与类实例创建表达式的求值类似，只要正常完成生成对对象的引用。方法引用表达式的计算不同于方法本身的调用。

首先，如果方法引用表达式以ExpressionName或Primary开头，则对该子表达式求值。如果子表达式的计算结果为null，则会引发NullPointerException，方法引用表达式会突然完成。如果子表达式突然完成，方法引用表达式也会因为同样的原因突然完成。

对于lambda表达式，我不确定，最终类型是在编译时从方法声明中派生的。这只是对实际情况的简化。但是让我们假设方法runThisLater已被声明为例如void runThisLater（SamType obj），其中SamType是一些函数接口，然后runThisLater（（）-

runThisLater(new SamType() {  
    void doSomething() { 
        field.method();
    }
});

其他信息：

• 15.27.4。Lambda表达式的运行时评估
• Lambda表达式的翻译
• Lambda的状态，版本3，其中提到了SAM。
• Lambda状态，最终。

Answer 2

由多条语句组成的长lambda表达式可能会降低代码的可读性。在这种情况下，在方法中提取这些语句并引用它可能是更好的选择。

另一个原因可能是可重用性。而不是复制

Answer 3

让我从一些角度来解释为什么我们在语言中添加了这个特性，而我们显然不需要（所有方法引用都可以表示为lambdas）

请注意，没有正确的答案。任何说“始终html" target="_blank">html" target="_blank">使用方法引用而不是lambda”或“始终使用lambda而不是方法引用”的人都应该被忽略。

这个问题在精神上与“我应该在什么时候使用命名类和匿名类”非常相似？答案是一样的：当你发现它更具可读性时。当然有肯定是一种或肯定是另一种的情况，但中间有很多灰色，必须使用判断。

方法refs背后的理论很简单：名字很重要。如果一个方法有一个名称，那么通常（但不总是！）是通过名称来引用它，而不是通过一包命令式的代码来调用它更清晰易读。

关于性能或字符计数的争论大多是转移注意力的，你应该忽略它们。目标是编写清晰的代码。经常（但不总是！）方法参考在这个指标上获胜，所以我们将其作为一个选项，用于这些情况。

关于方法引用是澄清还是混淆意图的一个关键考虑因素是，从上下文来看，所表示的函数的形状是否明显。在某些情况下（例如，map（Person:：getLastName）），从上下文中可以很清楚地看出，需要一个将一个事物映射到另一个事物的函数，在这种情况下，方法引用会发光。在其他情况下，使用方法ref需要读者想知道所描述的是什么样的函数；这是一个警告信号，表明lambda可能更具可读性，即使它更长。

最后，我们发现，大多数人一开始会避开方法引用，因为他们觉得自己比lambdas更新、更奇怪，所以最初觉得它们“不太可读”，但随着时间的推移，当他们习惯了语法时，通常会改变他们的行为，并尽可能地倾向于方法引用。因此，请注意，您自己的主观初始“不太可读”反应几乎肯定会导致某些方面的熟悉偏差，您应该给自己一个机会，在提出文体观点之前，让自己对两者都感到舒适。