Lambdaexpression式与方法参考
IntelliJ不断build议我用方法引用replace我的lambdaexpression式。
他们之间有没有客观的区别？
这个问题可能会（也应该）被closures，主要是基于意见的。 但是，在这之前，让我提供一些关于为什么我们将这个特性添加到语言中的一些观点，当然我们并没有严格要求（所有的方法参考都可以表示为lambdaexpression式）。
请注意， 没有正确的答案 。 任何人都说“总是使用方法ref而不是lambda”或“总是使用lambda而不是方法ref”应该被忽略。
这个问题在精神上非常类似于“我应该什么时候使用一个命名类与一个匿名类”？ 答案是一样的： 当你发现它更可读 。 肯定有一种情况肯定是另一种情况，但是中间是灰色的，必须使用判断。
方法背后的理论很简单： 名字很重要 。 如果一个方法有一个名字，那么通过名字引用它，而不是通过一个最终转向并调用它的命令行代码，通常（但并不总是）更清晰可读。
关于表演或数字的论点大多是红鲱鱼，你应该忽略它们。 目标是编写清晰的代码。 在这个度量标准中，经常（但并非总是）方法参考，所以我们把它们作为一个选项包含在这些情况下。
关于方法参考是否澄清或混淆意图的一个关键考虑因素是，从上下文中可以明显看出函数的forms是什么。 在某些情况下（例如， map(Person::getLastName) ，从上下文中可以很清楚地看到一个函数将一个事物映射到另一个事物上，并且在这种情况下，方法引用变得光芒四射。读者想知道正在描述什么样的函数;这是一个警告信号，即一个lambda可能更可读，即使更长。
最后，我们发现大多数人最初都是远离方法参考的，因为他们觉得比lambda更新，更怪，所以最初觉得它们“不太可读”，但随着时间的推移，当他们习惯了语法，一般会改变他们的行为，并尽可能地倾向于方法参考。 所以请注意，你自己的主观初始“不太可读”的反应几乎肯定会带来某些方面的亲属偏见，你应该给自己一个机会，在提出文体观点之前，两者都适应。
由多个语句组成的长lambdaexpression式可能会降低代码的可读性 。 在这种情况下，提取方法中的这些语句并引用它可能是更好的select。
另一个原因可能是可重用性 。 你可以构造一个方法，并从代码的不同位置调用它，而不是复制和粘贴你的lambdaexpression式。
