【发布时间】:2020-04-27 16:27:59
【问题描述】:
我在问自己 scope 函数背后的语言设计者的意图是什么,是否几乎每个人都在滥用它。
如果您在此处搜索堆栈溢出以获取 Kotlins 作用域函数的示例,您最终会得到这个公认的答案:https://stackoverflow.com/a/45977254/5122729
also { } 的给定答案是
也 - 当你想使用 apply 但不想遮蔽时使用它 这个
类水果篮{ 私有变量权重 = 0
fun addFrom(appleTree: AppleTree) { val apple = appleTree.pick().also { apple -> this.weight += apple.weight add(apple) } ... } ... fun add(fruit: Fruit) = ... }在此处使用 apply 会影响 this,因此 this.weight 将引用 苹果,而不是水果篮。
这也是我经常看到的用法。但如果我查看kotlinlang.org 的文档,他们显然是在说:
also适合执行一些获取上下文对象的操作 作为论据。也用于不改变 对象,例如记录或打印调试信息。通常,你 也可以从调用链中删除对的调用,而不会破坏 程序逻辑。
从这个角度来看,给定的示例将是错误的,因为如果删除它会破坏程序逻辑。对我来说,also 是一种 Javas peek (doc),它存在,但不应用于生产性程序逻辑。
谁能启发我?
【问题讨论】:
-
他们的意思是,如果你对一个对象做某事而不是对它做某事(配置它),那么在语义上将它视为参数而不是接收者更有意义。上面的例子完全符合这个想法。但是这个例子也是一个例子,如果没有范围函数,代码会更简洁易读。如果该函数还返回了苹果,那么使用它是有意义的,因此您没有将它分配给
val。 -
但是最后一句呢,那些调用通常可以在不破坏程序逻辑的情况下被删除?如果我从示例中删除 add 调用,结果将不再相同。
-
我明白了,我想它不符合这个想法,即它只是为了做一些日志记录。上面的示例是对它的一种毫无意义的使用,但有助于缩短检索某些内容、对其执行某些操作然后返回它的简单函数的代码。但我猜
with可以被认为是一种更易读的方法。我认为 also 的初衷是在不中断集合的情况下记录一系列函数式编程调用链中的内容。
标签: kotlin