Question

我是Scala的新手，但有一些Java背景。

在编写Scala代码时，以这种样式处理Option参数很有用：

val text = Option("Text")
val length = text.map(s => s.size)

但据我所知，每个s => s.size都会带来一个新的Function1[A, B]。如果我做了8次这样的转换，它将带来8个额外的类。绑定表单时，我非常重视这些片段，所以问题是：

我应该少用它，也许用if-notation替换它，或者这样的类泛滥对JVM来说不是很关键，或者Scala编译器可能会做某种魔术？

更新：一个更具体的例子是：

case class Form(name: Option[String], surname: Option[String])
val bindedForm = Form(Option("John"), Option("Smith"))
val person = new Person
bindedForm.name.foreach(a => person.setName(a))
bindedForm.surname.foreach(a => person.setSurname(a))

会产生两个不同的Function1[String, String]类吗？如果有数百次此类转换怎么办？

Answer 1

如果您正在为Android开发，那么您可能会使用Dalvik运行代码，这有一个恼人的64k方法限制（尽管有are ways around it）。由于每个类都需要几个方法（构造函数和应用程序），这可能是个问题。

否则，Sun / Oracle JVM上的类进入PermGen空间，如果确实需要，可以在启动JVM时调整。这没关系。是的，你会有很多课程，也许会有成千上万，但是JVM可以很好地处理它（至少如果你愿意为它提供预期的预测）。除非你知道你很可能遇到一些不寻常的约束，否则这不是你应该担心的事情。

更常见的是，人们可能担心创建所有这些功能会对性能造成影响 - 但如果你现在没有真正遇到这种惩罚，也不要担心;这是Scala编译器原则上可以解决的问题，并且它一直变得越来越聪明。所以只需用惯用的方式编写代码，除非它现在是一个很大的性能问题，只希望编译器能够拯救你。这将是一个不错的机会，你会发现更容易以“正确”的方式编写它，然后在需要时重构性能，而不是采用使用更笨拙的构造的策略以防万一是个问题。当然，有些地方你可能事先知道肯定会成为一个瓶颈，就像把你从一个巨大的文件中读取的每个字节包装在一个选项中，但除了那些明显的东西之外，你最好还是反应性地做已知的问题，而不是主动避免关闭。

斯卡拉。功能太多，课程太多了？

1 个答案: