Lambda 表达式与方法引用

让我提供一些关于为什么我们在语言中添加这个特性的观点，而显然我们并不是严格需要的（所有方法refs都可以表示为lambdas）。

请注意，没有正确的答案。任何说“总是使用方法ref而不是lambda”或“总是使用lambda而不是方法ref”的人都应该被忽略。

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

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

关于表演或关于计算角色的争论大多是红鲱鱼，你应该忽略它们。目标是编写非常清楚其功能的代码。通常（但并非总是！）方法引用在此指标上获胜，因此我们将它们作为选项包含在这些情况下使用。

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

最后，我们发现大多数人最初避开了方法引用，因为他们感觉比lambdas更新，更奇怪，所以最初发现它们“可读性较差”，但随着时间的推移，当他们习惯语法时，通常会改变他们的行为，并在可能的时候倾向于方法引用。因此，请注意，您自己主观的初始“可读性较差”的反应几乎肯定会带来熟悉度偏差的某些方面，在提出文体意见之前，您应该给自己一个机会来适应这两种情况。

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

另一个原因可能是可重用性。无需复制粘贴几个语句的 lambda 表达式，您可以构造一个方法并从代码的不同位置调用它。