Lambda表达式与方法引用 [英] Lambda expression vs method reference

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

问题描述

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

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

两者之间是否存在客观差异?

Is there any objective difference between both of them?

推荐答案

这个问题可能(并且应该)被关闭,主要是基于意见的。但是,在此之前,让我提供一些观点,说明为什么我们将这个功能添加到语言中,显然我们并不严格需要(所有方法引用都可以表示为lambdas。)

This question probably will (and should) be shut down as primarily opinion-based. But, before that happens, 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.)

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

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.

方法引用背后的理论很简单:名称很重要。如果一个方法有一个名称,那么通过名称引用它,而不是通过最终只是转身并调用它的命令包代码,通常(但不总是!)更清晰和可读。

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), 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 is longer.

最后,我们发现大多数人起初远离方法引用,因为他们觉得比lambdas更新,更怪异,因此最初发现它们不太可读,但随着时间的推移,当他们习惯了语法时,通常会改变他们的行为,并在他们可以的时候倾向于方法参考。所以请注意,你自己的主观初始不太可读的反应几乎肯定会带来一些熟悉偏见的方面。 ,你应该给自己一个机会在提出风格意见之前对两者都感到满意。

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 familarity bias, and you should give yourself a chance to get comfortable with both before rendering a stylistic opinion.

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

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