design-patterns - Scala 程序员 - "should there be one obvious way to do it"还是 "more than one way to do it"？

Question

我从事 Java 工作已经很长时间了，大约 6 个月前开始使用 Scala。我喜欢这门语言。我发现的一件事是，做事有多种方法。我不知道这是因为该语言的性质，还是因为它还很年轻并且在不断发展，习惯用法和最佳实践还没有出现。

令我惊讶的是，我一直是一个 Python 而非 Perl 的人，其中:

"There should be one-- and preferably only one --obvious way to do it."

对我来说比

更有意义

"There's more than one way to do it".

我很想知道您认为 Scala 适合这个规模，为什么？

<小时/>

报价:Python PEP20和 Perl quote

Answer 1

我使用 Scala 的经验是，做事的方法不止一种，但“最佳”做事方法相对较少。图书馆几乎没有无偿的选择来以不同的方式做事；当它这样做时，通常是为了在部分情况下实现额外的表现力、紧凑性或效率。

例如，如果你想对一个整数数组求和，你可以完全程序化，这会生成尽可能快的代码，但代价是有点笨拙——但如果这真的是时间——关键代码，这是解决问题的唯一最佳方法:

val array = Array(1,2,3,4,5)
var sum = 0
var index = 0
while (index < array.length) {
  sum += array(index)
  index += 1
}
sum

还有一些同样通用的函数方法，在处理基元时速度会更慢(这可能会随着 2.8 中的 @specialized 的改变而改变)，但不会那么乏味:

var sum = 0
Array(1,2,3,4,5).foreach(x => sum += x)
sum

然后还有一些不太通用的函数结构，专门针对此类问题(因为它出现了很多)，如果您想要干净、紧凑的代码，这是“最好的”:

Array(1,2,3,4,5).reduceLeft( _ + _ )

有时，有一些非常非通用的结构可以完全满足您的需求；以 Scala 2.8 为例:

Array(1,2,3,4,5).sum

因此，您可以在一般功率、紧凑性、清晰度和速度之间进行权衡，获得一系列的选择。如果您可以假设代码只需要非常熟悉 Scala 的人可以访问，并且您知道是否需要绝对最佳的性能，那么好的选择通常相当有限。但是，由于语言和库的表达能力，通常有很多可能但不是最理想的方法来完成任务。