Java Lambda 表达式与方法参考
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/24487805/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Lambda expression vs method reference
提问by Gerard
IntelliJ keeps proposing me to replace my lambda expressions with method references.
IntelliJ 一直建议我用方法引用替换我的 lambda 表达式。
Is there any objective difference between both of them?
两者之间有客观的区别吗?
回答by ovunccetin
Long lambda expressions consisting of several statements may reduce the readabilityof your code. In such a case, extracting those statements in a method and referencing it may be a better choice.
由多个语句组成的长 lambda 表达式可能会降低代码的可读性。在这种情况下,在方法中提取这些语句并引用它可能是更好的选择。
The other reason may be re-usability. Instead of copy&pasting your lambda expression of few statements, you can construct a method and call it from different places of your code.
另一个原因可能是可重用性。您可以构造一个方法并从代码的不同位置调用它,而不是复制和粘贴几个语句的 lambda 表达式。
回答by Brian Goetz
Let me offer some perspective on why we added this feature to the language, when clearly we didn't strictly need to (all methods refs can be expressed as lambdas.)
让我提供一些关于为什么我们将这个特性添加到语言中的观点,显然我们并不严格需要(所有方法 refs 都可以表示为 lambdas。)
Note that there is no right answer. Anyone who says "always use a method ref instead of a lambda" or "always use a lambda instead of a method ref" should be ignored.
请注意,没有正确答案。任何说“总是使用方法引用而不是 lambda”或“总是使用 lambda 而不是方法引用”的人都应该被忽略。
This question is very similar in spirit to "when should I use a named class vs an anonymous class"? And the answer is the same: when you find it more readable. There are certainly cases that are definitely one or definitely the other but there's a host of grey in the middle, and judgment must be used.
这个问题在精神上与“我什么时候应该使用命名类与匿名类”非常相似?答案是一样的:当你发现它更具可读性时。肯定有一些情况肯定是一个或肯定是另一个,但中间有很多灰色,必须使用判断。
The theory behind method refs is simple: names matter. If a method has a name, then referring to it by name, rather than by an imperative bag of code that ultimately just turns around and invokes it, is often (but not always!) more clear and readable.
方法 refs 背后的理论很简单:名称很重要。如果一个方法有一个名字,那么通过名字来引用它,而不是通过最终只是调用它的命令式代码包,通常(但不总是!)更清晰易读。
The arguments about performance or about counting characters are mostly red herrings, and you should ignore them. The goal is writing code that is crystal clear what it does. Very often (but not always!) method refs win on this metric, so we included them as an option, to be used in those cases.
关于性能或计数字符的争论大多是红鲱鱼,你应该忽略它们。目标是编写清晰明确的代码。很多时候(但不总是!)方法引用在这个指标上获胜,所以我们将它们作为一个选项包含在内,以用于这些情况。
A key consideration about whether method refs clarify or obfuscate intent is whether it is obvious from context what is the shape of the function being represented. In some cases (e.g., map(Person::getLastName)
, its quite clear from the context that a function that maps one thing to another is required, and in cases like this, method references shine. In others, using a method ref requires the reader to wonder about what kind of function is being described; this is a warning sign that a lambda might be more readable, even if it is longer.
关于方法引用是澄清还是混淆意图的一个关键考虑因素是从上下文中是否可以明显看出所表示的函数的形状是什么。在某些情况下(例如,map(Person::getLastName)
从上下文中可以清楚地看出,需要一个将一件事映射到另一件事的函数,在这种情况下,方法引用大放异彩。在其他情况下,使用方法 ref 需要读者想知道是什么类型的函数正在被描述;这是一个警告信号,表明 lambda 可能更具可读性,即使它更长。
Finally, what we've found is that most people at firststeer away from method refs because they feel even newer and weirder than lambdas, and so initially find them "less readable", but over time, when they get used to the syntax, generally change their behavior and gravitate towards method references when they can. So be aware that your own subjective initial "less readable" reaction almost certainly entails some aspect of familarity bias, and you should give yourself a chance to get comfortable with both before rendering a stylistic opinion.
最后,我们发现大多数人一开始会避开方法引用,因为他们感觉比 lambda 更新颖、更奇怪,因此最初发现它们“可读性差”,但随着时间的推移,当他们习惯了语法时,通常会改变他们的行为并在可能的情况下倾向于方法引用。因此请注意,您自己的主观初始“可读性较差”的反应几乎肯定会导致某些方面的熟悉性偏见,并且您应该在呈现文体意见之前给自己一个机会来适应两者。