Lambda 表达式与方法参考 [英] Lambda expression vs method reference

查看:29
本文介绍了Lambda 表达式与方法参考的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

IntelliJ keeps proposing me to replace my lambda expressions with method references.

两者之间有客观的区别吗?

Is there any objective difference between both of them?

推荐答案

让我谈谈为什么我们在语言中添加这个特性,显然我们并不严格需要(所有方法 refs 都可以表示为 lambdas.)

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.)

请注意,没有正确答案.任何说总是使用方法引用而不是 lambda"的人或总是使用 lambda 而不是方法引用";应该被忽略.

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.

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

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.

方法 refs 背后的理论很简单:名称很重要.如果一个方法有一个名字,那么通过名字来引用它,而不是通过一个命令包来调用它,通常(但不总是!)更清晰易读.

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.

关于性能或计算字符的争论大多是红鲱鱼,你应该忽略它们.目标是编写清晰明确的代码.很多时候(但不总是!)方法引用在这个指标上获胜,所以我们将它们作为一个选项包含在内,以用于这些情况.

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.

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

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), it's 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.

最后,我们发现大多数人一开始会避开方法引用,因为他们觉得比 lambda 更新颖、更奇怪,因此最初发现它们不太可读",但是随着时间的推移,当他们习惯了语法时,通常会改变他们的行为并尽可能地倾向于方法引用.所以请注意,您自己的主观首字母可读性较差"反应几乎肯定会导致熟悉偏见的某些方面,在提出风格意见之前,您应该给自己一个机会让自己适应这两种情况.

Finally, what we've found is that most people at first steer 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 familiarity bias, and you should give yourself a chance to get comfortable with both before rendering a stylistic opinion.

这篇关于Lambda 表达式与方法参考的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆