Effective Scala

序言

格式化

代码格式化的规范并不重要，只要它们实用。它的定义形式没有先天的好与坏，几乎每个人都有自己的偏好。然而，对于一贯地采用同一格式化规则的总会增加可读性。已经熟悉某种特定风格的读者不必非要去掌握另一套当地习惯，或译解另一个角落里的语言语法。

这对Scala来说也特别重要，因为它的语法高度的重叠。一个例子是方法调用：方法调用可以用“.”后边跟圆括号，或不使用“.”，后边用空格加不带圆括号(针对空元或一元方法)方式调用。此外，不同风格的方法调用揭露了它们在语法上不同的分歧(ambiguities)。当然一致的应用慎重的选择一组格式化规则，对人和机器来说都会消除大量的歧义。

空格

用两个空格缩进。避免每行长度超过100列。在两个方法、类、对象定义之间使用一个空白行。

命名

对作用域较短的变量使用短名字：

is, js 和 ks等可出现在循环中。

对作用域较长的变量使用长名字：

外部APIs应该用长的，不需加以说明便可理解的名字。例如：Future.collect 而非 Future.all

使用通用的缩写，避开隐秘难懂的缩写：

例如每个人都知道 ok,err, defn等缩写的意思，而sfri是不常用的。

不要在不同用途时重用同样的名字：

使用val(注：Scala中的不可变类型)

避免用 `声明保留字变量：

用typ替代 `type`

用主动语态(active)来命名有副作用的操作：

user.activate()而非 user.setActive()

对有返回值的方法使用具有描述性的名字：

src.isDefined 而非src.defined

getters不采用前缀get：

用get是多余的: site.count而非site.getCount

不必重复已经被package或object封装过的名字：

使用：

object User {
  def get(id: Int): Option[User]
}

而非：

object User {
  def getUser(id: Int): Option[User]
}

相比 get 方法 getUser 方法中的User是多余的，并不能提供额外的信息。

Imports

对引入行按字母顺序排序：

这样机方便了视觉上的检查，也简化了自动操作。

当从一个包中引入多个时，用花括号：

import com.twitter.concurrent.{Broker, Offer}

当引入超过6个时使用通配符：

e.g.: import com.twitter.concurrent._
不要轻率的使用: 一些包导入了太多的名字

当引入集合的时候，通过用import scala.collections.immutable(不可变集合)或scala.collections.mutable(可变集合)来限定名称

可变和不可变集合有相同的名字。限定名称让读者很明确知道使用的是哪个变量(e.g. "immutable.Map")

(译注，通常也会默认immutable，而在使用mutable时显示引入)

不要使用来自其它包的相对引用：

避免

import com.twitter
import concurrent

而应该用清晰的：

import com.twitter.concurrent

(译注，实际上上面的import不能编译通过，第二个import应该为：import twitter.concurrent 即import一个包实际是定义了这个包的别名。)

将import放在文件的头部：

读者可以在一个地方参考所有的引用。

花括号

花括号用于创建复合表达式，复合表达式的返回值是最后一个表达式。避免对简单的表达式采用花括号；写成：

 def square(x: Int) = x*x

而不是：

 def square(x: Int) = {
   x * x
 }

尽管第二种方式用在区分方法体的语句构成很诱人。第一种选择更加简洁，易读。避免语句上的繁文缛节，除非需要阐明。

模式匹配

尽可能直接在函数定义的地方使用模式匹配。例如，下面的写法 match应该被折叠起来(collapse)

 list map { item =>
   item match {
     case Some(x) => x
     case None => default
   }
 }

用下面的写法替代：

 list map {
   case Some(x) => x
   case None => default
 }

它很清晰的表达了 list中的元素都被映射，间接的方式让人不容易明白。

注释

类型和泛型

类型系统的首要目的是检测程序错误。类型系统有效的提供了一个静态检测的有限形式，允许我们代码中明确某种类型的变量并且编译器可以验证。类型系统当然也提供了其他好处，但错误检测是他存在的理由(Raison d’Être)

我们使用类型系统应当反映这一目标，但我们必须考虑到读者（译注：读你代码的人）：明智地使用类型可以增加清晰度，而过份聪明只会迷乱。

返回类型注解(annotation)

尽管Scala允许返回类型是可以省略的，加上它们提供了很好的文档：这对public方法特别重要。而当一个方法不需要对外暴露，并且它的返回值类型是显而易见的时候，则可以直接省略。

在使用混入(mixin)实例化对象时这一点尤其重要，Scala编译器为这些对象创造了单类。例如：

 trait Service
 def make() = new Service {
   def getId = 123
 }

上面的make不需要定义返回类型为Service；编译器会创建一个加工过的类型: Object with Service{def getId:Int}(译注:with是Scala里的mixin的语法)。若用一个显式的注释：

 def make(): Service = new Service{}

现在作者则不必改变make方法的公开类型而随意的混入(mix in) 更多的特质(traits)，使向后兼容很容易实现。

变型

变型(Variance)发生在泛型与子类型化(subtyping)结合的时候。与容器类型的子类型化有关，它们定义了对所包含的类型如何子类型化。因为Scala有声明点变型(declaration site variance)注释（annotation），公共库的作者——特别是集合——必须有丰富的注释器。这些注释对共享代码的可用性很重要，但滥用也会很危险。

不可变(invariants)是Scala类型系统中高级部分，但也是必须的一面，因为它有助于子类型化的应用，应该广泛(并且正确)地使用。

不可变(Immutable)集合应该是协变的(covariant)。接受容器化类型得方法应该适当地降级(downgrade)集合：

 trait Collection[+T] {
   def add[U >: T](other: U): Collection[U]
 }

可变(mutable)集合应该是不可变的(invariant). 协变对于可变集合是典型无效的。考虑：

 trait HashSet[+T] {
   def add[U >: T](item: U)
 }

和下面的类型层级：

 trait Mammal
 trait Dog extends Mammal
 trait Cat extends Mammal

如果我现在有一个狗(dog)的 HashSet：

 val dogs: HashSet[Dog]

把它作为一个哺乳动物的Set，增加一只猫(cat)

 val mammals: HashSet[Mammal] = dogs
 mammals.add(new Cat{})

这将不再是一个只存储狗(dog)的HashSet！

类型别名

类型别名应当在其提供了便捷的命名或阐明意图时使用，但对于自解释（不言自明）的类型不要使用类型别名。比如

 () => Int

比下面定义的别名IntMarker更清晰

 type IntMaker = () => Int
 IntMaker

但，下面的别名:

 class ConcurrentPool[K, V] {
   type Queue = ConcurrentLinkedQueue[V]
   type Map   = ConcurrentHashMap[K, Queue]
   ...
 }

是有用的，因为它表达了目的并更加简短。

当使用类型别名的时候不要使用子类型化(subtyping)

 trait SocketFactory extends (SocketAddress => Socket)

SocketFactory 是一个生产Socket的方法。使用一个类型别名更好：

 type SocketFactory = SocketAddress => Socket

我们现在可以对 SocketFactory类型的值 提供函数字面量(function literals) ,也可以使用函数组合：

 val addrToInet: SocketAddress => Long
 val inetToSocket: Long => Socket

 val factory: SocketFactory = addrToInet andThen inetToSocket

类型别名通过用 package object 将名字绑定在顶层:

 package com.twitter
 package object net {
   type SocketFactory = (SocketAddress) => Socket
 }

注意类型别名不是新类型——他们等价于在语法上用别名代替了原类型。

隐式转换

隐式转换是类型系统里一个强大的功能，但应当谨慎地使用。它们有复杂的解决规则， 使得通过简单的词法检查领会实际发生了什么很困难。在下面的场景使用隐式转换是OK的：

• 扩展或增加一个Scala风格的集合
• 适配或扩展一个对象(pimp my library模式）（译注参见：http://www.artima.com/weblogs/viewpost.jsp?thread=179766)
• 通过提供约束证据来加强类型安全。
• 提供了类型的证据 (typeclassing，haskell中的概念，指定义一组函数，其实现因所给的数据类型不同而不同)
• 用于Manifests (注：Manifest[T]包含类型T的运行时信息)

如果你发现自己在用隐式转换，总要问问自己是否不使用这种方式也可以达到目的。

不要使用隐式转换对两个相似的数据类型做自动转换(例如，把list转换为stream);显示地做更好，因为不同类型有不同的语意，读者应该意识到这些含义。 译注： 1）一些单词的意义不同，但翻译为中文时可能用的相似的词语，比如mutable， Immutable 这两个翻译为可变和不可变，它们是指数据的可变与不可变。 variance, invariant 也翻译为 可变和不可变，（variance也翻译为“变型”），它们是指类型的可变与不可变。variance指支持协变或逆变的类型，invariant则相反。

集合

Scala有一个非常通用，丰富，强大，可组合的集合库；集合是高阶的(high level)并暴露了一大套操作方法。很多集合的处理和转换可以被表达的简洁又可读，但不审慎地用它们的功能也会导致相反的结果。每个Scala程序员应该阅读 集合设计文档；通过它可以很好地洞察集合库，并了解设计动机。

总使用最简单的集合来满足你的需求

层级

集合库很大：除了精心设计的层级(Hierarchy)——根是 Traversable[T] —— 大多数集合都有不可变(immutable)和可变(mutable)两种变体。无论其复杂性，下面的图表包含了可变和不可变集合层级的重要差异。

Iterable[T] 是所有可遍历的集合，它提供了迭代的方法(foreach)。Seq[T] 是有序集合，Set[T]是数学上的集合(无序且不重复)，Map[T]是关联数组，也是无序的。

集合的使用

优先使用不可变集合。不可变集合适用于大多数情况，让程序易于理解和推断，因为它们是引用透明的( referentially transparent )因此缺省也是线程安全的。

使用可变集合时，明确地引用可变集合的命名空间。不要用使用import scala.collection.mutable._ 然后引用 Set ，应该用下面的方式替代：

 import scala.collections.mutable
 val set = mutable.Set()

这样就很明确在使用一个可变集合。

使用集合类型缺省的构造函数。每当你需要一个有序的序列(不需要链表语义)，用 Seq() 等诸如此类的方法构造：

 val seq = Seq(1, 2, 3)
 val set = Set(1, 2, 3)
 val map = Map(1 -> "one", 2 -> "two", 3 -> "three")

这种风格从语意上分离了集合与它的实现，让集合库使用更适当的类型：你需要Map，而不是必须一个红黑树(Red-Black Tree，注：红黑树TreeMap是Map的实现者)

此外，默认的构造函数通常使用专有的表达式，例如：Map() 将使用有3个成员的对象(专用的Map3类)来映射3个keys。

上面的推论是：在你自己的方法和构造函数里，适当地接受最宽泛的集合类型。通常可以归结为Iterable, Seq, Set, 或 Map中的一个。如果你的方法需要一个 sequence，使用 Seq[T]，而不是List[T]

风格

函数式编程鼓励使用流水线转换将一个不可变的集合塑造为想要的结果。这常常会有非常简明的方案，但也容易迷糊读者——很难领悟作者的意图，或跟踪所有隐含的中间结果。例如，我们想要从一组语言中汇集不同的程序语言的投票，按照得票的顺序显示(语言，票数)：

 val votes = Seq(("scala", 1), ("java", 4), ("scala", 10), ("scala", 1), ("python", 10))
 val orderedVotes = votes
   .groupBy(_._1)
   .map { case (which, counts) =>
     (which, counts.foldLeft(0)(_ + _._2))
   }.toSeq
   .sortBy(_._2)
   .reverse

上面的代码简洁并且正确，但几乎每个读者都不能理解作者的原本意图。一个策略是声明中间结果和参数：

 val votesByLang = votes groupBy { case (lang, _) => lang }
 val sumByLang = votesByLang map { case (lang, counts) =>
   val countsOnly = counts map { case (_, count) => count }
   (lang, countsOnly.sum)
 }
 val orderedVotes = sumByLang.toSeq
   .sortBy { case (_, count) => count }
   .reverse

代码也同样简洁，但更清晰的表达了转换的发生(通过命名中间值)，和正在操作的数据的结构(通过命名参数)。如果你担心这种风格污染了命名空间，用大括号{}来将表达式分组:

 val orderedVotes = {
   val votesByLang = ...
   ...
 }

性能

高阶集合库（通常也伴随高阶构造）使推理性能更加困难：你越偏离直接指示计算机——即命令式风格——就越难准确预测一段代码的性能影响。然而推理正确性通常很容易；可读性也是加强的。在Java运行时使用Scala使得情况更加复杂，Scala对你隐藏了装箱(boxing)/拆箱(unboxing)操作，可能引发严重的性能或内存空间问题。

Java集合

使用 scala.collection.JavaConverters 与Java集合交互。它有一系列的隐式转换，添加了asJava和asScala的转换方法。使用它们这些方法确保转换是显式的，有助于阅读：

 import scala.collection.JavaConverters._

 val list: java.util.List[Int] = Seq(1,2,3,4).asJava
 val buffer: scala.collection.mutable.Buffer[Int] = list.asScala

并发

现代服务是高度并发的—— 服务器通常是在10–100秒内并列上千个同时的操作——处理隐含的复杂性是创作健壮系统软件的中心主题。

线程提供了一种表达并发的方式：它们给你独立的，堆共享的(heap-sharing)由操作系统调度的执行上下文。然而，在Java里线程的创建是昂贵的，是一种必须托管的资源，通常借助于线程池。这对程序员创造了额外的复杂，也造成高度的耦合：很难从所使用的基础资源中分离应用逻辑。

当创建高度分散(fan-out)的服务时这种复杂度尤其明显： 每个输入请求导致一大批对另一层系统的请求。在这些系统中，线程池必须被托管以便根据每一层请求的比例来平衡：一个线程池的管理不善会导致另一个线程池也出现问题。

一个健壮系统必须考虑超时和取消，两者都需要引入更多“控制”线程，使问题更加复杂。注意若线程很廉价这些问题也将会被削弱：不再需要一个线程池，超时的线程将被丢弃，不再需要额外的资源管理。

因此，资源管理危害了模块化。

Future

使用Future管理并发。它们将并发操作从资源管理里解耦出来：例如，Finagle（译注：twitter的一个RFC框架）以有效的方式在少量线程上实现并发操作的复用。Scala有一个轻量级的闭包字面语法(literal syntax)，所以Futures引入了很少的语法开销，它们成为很多程序员的第二本能。

Futures允许程序员用一种可扩充的，有处理失败原则的声明风格，来表达并发计算。这些特性使我们相信它们尤其适合在函数式编程中用，这也是鼓励使用的风格。

更愿意转换（transforming）future而非自己创造。Future的转换(transformations)确保失败会传播，可以通过信号取消，对于程序员来说不必考虑Java内存模型的含义。甚至一个仔细的程序员会写出下面的代码，顺序地发出10次RPC请求而后打印结果：

 val p = new Promise[List[Result]]
 var results: List[Result] = Nil
 def collect() {
   doRpc() onSuccess { result =>
     results = result :: results
     if (results.length < 10)
       collect()
     else
       p.setValue(results)
   } onFailure { t =>
     p.setException(t)
   }
 }

 collect()
 p onSuccess { results =>
   printf("Got results %s\n", results.mkString(", "))
 }

程序员不得不确保RPC失败是可传播的，代码散布在控制流程中；糟糕的是，代码是错误的！ 没有声明results是volatile，我们不能确保results每次迭代会保持前一次值。Java内存模型是一个狡猾的野兽，幸好我们可以通过用声明式风格(declarative style)避开这些陷阱：

 def collect(results: List[Result] = Nil): Future[List[Result]] =
   doRpc() flatMap { result =>
     if (results.length < 9)
       collect(result :: results)
     else
       result :: results
   }

 collect() onSuccess { results =>
   printf("Got results %s\n", results.mkString(", "))
 }

我们用flatMap顺序化操作，把我们处理中的结果预追加(prepend)到list中。这是一个通用的函数式编程习语的Futures译本。这是正确的，不仅需要的样板代码(boilerplate)可以减少，易出错的可能性也会减少，并且读起来更好。

Future组合子(combinators)的使用。当操作多个futures时，Future.select，Future.join和Future.collect应该被组合编写出通用模式。

集合

并发集合的主题充满着意见、微妙(subtleties)、教条、恐惧/不确定/怀疑(FUD)。在大多实际场景都不存在问题：总是先用最简单,最无聊，最标准的集合解决问题。 在你知道不能使用synchronized前不要去用一个并发集合：JVM有着老练的手段来使得同步开销更小，所以它的效率能让你惊讶。

如果一个不可变(immutable)集合可行，就尽可能用不可变集合——它们是指称透明的(referentially transparent)，所以在并发上下文推断它们是简单的。不可变集合的改变通常用更新引用到当前值(一个var单元或一个AtomicReference)。必须小心正确地应用：原子型的(atomics)必须重试(retried)，变量(var类型的)必须声明为volatile以保证它们发布(published)到它们的线程。

可变的并发集合有着复杂的语义，并利用Java内存模型的微妙的一面，所以在你使用前确定你理解它的含义——尤其对于发布更新(新的公开方法)。同步的集合同样写起来更好：像getOrElseUpdate操作不能够被并发集合正确的实现，创建复合(composite)集合尤其容易出错。

控制结构

函数式风格的程序倾向于需要更少的传统的控制结构，并且使用声明式风格写的程序读起来更好。这通常意味着打破你的逻辑，拆分到若干个小的方法或函数，用匹配表达式(match expression)把他们粘在一起。函数式程序也倾向于更多面向表达式(expression-oriented)：条件分支是同一类型的值计算，for（..) yield 表达式，以及递归都是司空见惯的。

递归

用递归术语来表达你的问题常常会使问题简化，如果应用了尾递归优化(可以通过@tailrec注释检测)，编译器甚至会将你的代码转换为正常的循环。对比一个标准的命令式版本的堆排序(fix-down):

 def fixDown(heap: Array[T], m: Int, n: Int): Unit = {
   var k: Int = m
   while (n >= 2*k) {
     var j = 2*k
     if (j < n && heap(j) < heap(j + 1))
       j += 1
     if (heap(k) >= heap(j))
       return
     else {
       swap(heap, k, j)
       k = j
     }
   }
 }

返回(Return)

并不是说命令式结构没有价值。在很多例子中它们很适合于提前终止计算而非对每个可能终止的点存在一个条件分支：的确在上面的fixDown函数，如果我们已经在堆的结尾，一个return用于提前终止。

Returns可以用于切断分支和建立不变量(establish invariants)。这减少了嵌套，并且容易推断后续的代码的正确性，从而帮助了读者。这尤其适用于卫语句(guard clauses)：

 def compare(a: AnyRef, b: AnyRef): Int = {
   if (a eq b)
     return 0

   val d = System.identityHashCode(a) compare System.identityHashCode(b)
   if (d != 0)
     return d

   // slow path..
 }

使用return增加了可读性

 def suffix(i: Int) = {
   if      (i == 1) return "st"
   else if (i == 2) return "nd"
   else if (i == 3) return "rd"
   else             return "th"
 }

上面是针对命令式语言的，在Scala中鼓励省略return

 def suffix(i: Int) =
   if      (i == 1) "st"
   else if (i == 2) "nd"
   else if (i == 3) "rd"
   else             "th"

但使用模式匹配更好：

 def suffix(i: Int) = i match {
   case 1 => "st"
   case 2 => "nd"
   case 3 => "rd"
   case _ => "th"
 }

注意，return会有隐性开销：当在闭包内部使用时。

 seq foreach { elem =>
   if (elem.isLast)
     return

   // process...
 }

在字节码层实现为一个异常的捕获/声明(catching/throwing)对，用在频繁的执行的代码中，会有性能影响。

for循环和for推导

for对循环和聚集提供了简洁和自然的表达。 它在扁平化(flattening)很多序列时特别有用。for语法通过分配和派发闭包隐藏了底层的机制。这会导致意外的开销和语义；例如：

 for (item <- container) {
   if (item != 2) return
 }

如果容器延迟计算(delays computation)会引起运行时错误，使返回不在本地上下文 (making the return nonlocal)

因为这些原因，常常更可取的是直接调用foreach, flatMap, map和filter —— 但在其意义清楚的时候使用for。

要求require和断言(assert)

要求(require)和断言(assert)都起到可执行文档的作用。两者都在类型系统不能表达所要求的不变量(invariants)的场景里有用。 assert用于代码假设的不变量(invariants) （内部或外部的） 例如：(译注，不变量 invariant 是指类型不可变，即不支持协变或逆变的类型变量)

 val stream = getClass.getResourceAsStream("someclassdata")
 assert(stream != null)

相反，require用于表达API契约：

 def fib(n: Int) = {
   require(n > 0)
   ...
 }

函数式编程

面向值（value-oriented ）编程有很多优势，特别是用在与函数式编程结构相结合。这种风格强调值的转换（译注：由一个不变的值生成另一个不变的值）而非状态的改变，生成的代码是指称透明的(referentially transparent)，提供了更强的不变型(invariants)，因此容易实现。Case类(也被翻译为样本类)，模式匹配，解构绑定(destructuring bindings)，类型推断，轻量级的闭包和方法创建语法都是这一类的工具。

Case类模拟代数数据类型

Options

Option类型是一个容器，空(None)或满(Some(value))二选一。它提供了使用null的另一种安全选择，应该尽可能的替代null。它是一个集合(最多只有一个元素)并用集合操所修饰，尽量用Option。

用

 var username: Option[String] = None
 ...
 username = Some("foobar")

代替

 var username: String = null
 ...
 username = "foobar"

因为前者更安全：Option类型静态地强制username必须对空(emptyness)做检测。

对一个Option值做条件判断应该用foreach

 if (opt.isDefined)
   operate(opt.get)

上面的代码应该用下面的方式替代：

 opt foreach { value =>
   operate(value)}

风格可能看起来有些古怪，但更安全，更简洁。如果两种情况都有(Option的None或Some)，用模式匹配

 opt match {
   case Some(value) => operate(value)
   case None => defaultAction()
 }

但如果缺少的是缺省值，用getOrElse方法：

 operate(opt getOrElse defaultValue)

模式匹配

模式匹配(x match { …) 在良好的Scala代码中无处不在：用于合并条件执行、解构(destructuring) 、在构造中造型。使用好模式匹配可以增加程序的明晰度和安全性。

使用模式匹配实现类型转换：

 obj match {
   case str: String => ...
   case addr: SocketAddress => ...

模式匹配在和解构(destructuring)联合使用时效果最好（例如你要匹配case类）；下面的写法

 animal match {
   case dog: Dog => "dog (%s)".format(dog.breed)
   case _ => animal.species
   }

应该被替代为：

 animal match {
   case Dog(breed) => "dog (%s)".format(breed)
   case other => other.species
 }

偏函数

Scala提供了定义PartialFunction的语法简写：

 val pf: PartialFunction[Int, String] = {
   case i if i%2 == 0 => "even"
 }

它们也可能和 orElse 组合:

 val tf: (Int => String) = pf orElse { case _ => "odd"}

 tf(1) == "odd"
 tf(2) == "even"

偏函数出现在很多场景，并以PartialFunction有效地编码 ，例如 方法参数：

 trait Publisher[T] {
   def subscribe(f: PartialFunction[T, Unit])
 }

 val publisher: Publisher[Int] = ..
 publisher.subscribe {
   case i if isPrime(i) => println("found prime", i)
   case i if i%2 == 0 => count += 2
   /* ignore the rest */
 }

或在返回一个Option的情况下：

 // Attempt to classify the the throwable for logging.
 type Classifier = Throwable => Option[java.util.logging.Level]

可以更好的用PartialFunction表达

 type Classifier = PartialFunction[Throwable, java.util.Logging.Level]

因为它提供了更好的可组合性：

 val classifier1: Classifier
 val classifier2: Classifier

 val classifier = classifier1 orElse classifier2 orElse { _ => java.util.Logging.Level.FINEST }

解构绑定

解构绑定与模式匹配有关。它们用了相同的机制，但解构绑定可应用在当匹配只有一种选项的时候 (以免你接受异常的可能)。解构绑定特别适用于元组(tuple)和样本类(case class).

 val tuple = ('a', 1)
 val (char, digit) = tuple

 val tweet = Tweet("just tweeting", Time.now)
 val Tweet(text, timestamp) = tweet

惰性赋值

当使用lazy修饰一个val成员时，其赋值情况是在需要时才赋值的(by need)，因为Scala中成员与方法是等价的（除了private[this]成员）

 lazy val field = computation()

相当于下面的简写:

 var _theField = None
 def field = if (_theField.isDefined) _theField.get else {
   _theField = Some(computation())
   _theField.get
 }

也就是说，它在需要时计算结果并会记住结果，在要达到这种目的时使用lazy成员；但当语意上需要惰性赋值时(by semantics)，要避免使用惰性赋值，这种情况下，最好显式赋值因为它使得成本模型是明确的，并且副作用被严格的控制。

Lazy成员是线程安全的。

传名调用

方法参数可以指定为传名参数 (by-name) 意味着参数不是绑定到一个值，而是一个可能需要反复进行的计算。这一特性需要小心使用； 期待传值(by-value)语法的调用者会感到惊讶。这一特性的动机是构造语法自然的 DSLs——使新的控制结构可以看起来更像本地语言特征。

只在下面的控制结构中使用传名调用, 调用者明显传递的是一段代码块(block)而非一个确定的计算结果。传名参数必须放在参数列表的最后一位。当使用传名调用时，确保方法名称让调用者明显感知到方法参数是传名参数。

当你想要一个值被计算多次，特别是这个计算会引起副作用时，使用显式函数：

 class SSLConnector(mkEngine: () => SSLEngine)

这样意图很明确，调用者不会感到惊奇。

flatMap

flatMap——结合了map 和 flatten —— 的使用要特别小心，它有着难以琢磨的威力和强大的实用性。类似它的兄弟 map，它也是经常在非传统的集合中使用的，例如 Future , Option。它的行为由它的（函数）签名揭示；对于一些容器 Container[A]

 flatMap[B](f: A => Container[B]): Container[B]

flatMap对集合中的每个元素调用了 函数 f 产生一个新的集合，将它们全部 flatten 后放入结果中。例如，获取两个字符的字符串的所有排列，相同的字符不能出现两次

 val chars = 'a' to 'z'
 val perms = chars flatMap { a =>
   chars flatMap { b =>
     if (a != b) Seq("%c%c".format(a, b))
     else Seq()
   }
 }

等价于下面这段更简洁的 for-comprehension （基本就是针对上面的语法糖）

 val perms = for {
   a <- chars
   b <- chars
   if a != b
 } yield "%c%c".format(a, b)

flatMap在处理Options常常很有用—— 它将多个options链合并为一个，

 val host: Option[String] = ..
 val port: Option[Int] = ..

 val addr: Option[InetSocketAddress] =
   host flatMap { h =>
     port map { p =>
       new InetSocketAddress(h, p)
     }
   }

也可以使用更简洁的for来实现：

 val addr: Option[InetSocketAddress] = for {
   h <- host
   p <- port
 } yield new InetSocketAddress(h, p)

面向对象的编程

Scala的博大很大程度上在于它的对象系统。Scala中所有的值都是对象，就这一意义而言Scala是门纯粹的语言；基本类型和组合类型没有区别。Scala也提供了mixin的特性允许更多正交地、细粒度地构造一些在编译时受益于静态类型检测的可被灵活组装的模块。

依赖注入

在我们的使用中，我们发现Scala本身删除了很多经典(构造函数)依赖注入的语法开销，我们更愿意就这样用: 它更清晰，依赖仍然植根于（构造）类型，而类构造语法是如此微不足道而变得轻而易举。有些无聊，简单，但有效。对模块化编程时使用依赖注入，特别是，组合优于继承—这使得程序更加模块化和可测试的。当遇到需要继承的情况，问问自己：在语言缺乏对继承支持的情况下如何构造程序？答案可能是令人信服的。

依赖注入典型的使用到 trait （译注：可以理解为和Java中Interface相似）

 trait TweetStream {
   def subscribe(f: Tweet => Unit)
 }
 class HosebirdStream extends TweetStream ...
 class FileStream extends TweetStream ..

 class TweetCounter(stream: TweetStream) {
   stream.subscribe { tweet => count += 1 }
 }

这是常见的注入工厂 — 用于产生其他对象的对象。在这些例子中，更青睐用简单的函数而非专有的工厂类型。

 class FilteredTweetCounter(mkStream: Filter => TweetStream) {
   mkStream(PublicTweets).subscribe { tweet => publicCount += 1 }
   mkStream(DMs).subscribe { tweet => dmCount += 1 }
 }

Trait

依赖注入不妨碍使用公共接口，或在trait中实现公共代码。恰恰相反—正是因为以下原因而高度鼓励使用trait：一个具体的类可以实现多接口(traits)，公共的代码可以通过这些类复用。

保持traits简短并且是正交的：不要把分离的功能混在一个trait里，考虑将最小的相关的意图放在一起。例如，想象一下你要做一些IO的操作：

 trait IOer {
   def write(bytes: Array[Byte])
   def read(n: Int): Array[Byte]
 }

分离两个行为：

 trait Reader {
   def read(n: Int): Array[Byte]
 }
 trait Writer {
   def write(bytes: Array[Byte])
 }

可以将它们以混入(mix)的方式实现一个IOer : new Reader with Writer...接口最小化促使更好的正交性和更清晰的模块化。

可见性

Scala有很丰富的可见性修饰。使用这些可见性修饰很重要，因为它们定义了哪些构成公开API。公开APIs应该限制，这样用户不会无意中依赖实现细节并限制了作者修改它们的能力: 它们对于好的模块化设计是至关重要的。一般来说，扩展公开APIs比收缩公开的APIs容易的多。差劲的注释（annotation）也能危害到你代码向后的二进制兼容性。（译注：comments和annotation都可翻译成注释，但意义不同。annotation在Java和Scala有特定的含义）

private[this]

一个类的成员标记为私有的，

 private val x: Int = ...

它对这个类的所有实例来说都是可见的（但对其子类不可见）。大多情况，你想要的是 private[this] 。

 private[this] val: Int = ..

这个修饰限制了它只对当前特定的实例可见。Scala编译器会把private[this]翻译为一个简单的字段访问(因为访问仅限于静态定义的类)，这样有时有助于性能优化。

单例类型

在Scala中创建单例类型是很常见的，例如：

 def foo() = new Foo with Bar with Baz {
   ...
 }

在这种情况下，可以通过声明返回类型来限制可见性：

 def foo(): Foo with Bar = new Foo with Bar with Baz {
   ...
 }

foo()方法的调用者会看到以返回实例(Foo with Bar)的受限视图。

结构类型

不要在正常情况下使用结构类型。结构类型有着便利且强大的特性，但不幸的是在JVM上的实现不是很高效。 然而——由于实现的怪癖——它提对执行反射(reflection)供了很好的简写形式。

 val obj: AnyRef
 obj.asInstanceOf[{def close()}].close()

垃圾回收

我们对生产中花了很多时间来调整垃圾回收。垃圾回收的关注点与Java大致相似，尽管一些惯用的Scala代码比起惯用的Java代码会容易产生更多(短暂的)垃圾——函数式风格的副产品。Hotspot的分代垃圾收集通常使这不成问题，因为短暂的(short-lived)垃圾在大多情形下会被有效的释放掉。

Java 兼容性

当我们写的Scala代码被Java调用时，我们要确保从Java来用仍然习惯。这常常不需要额外的努力——class和纯的trait等价于Java的中的对应类型 —— 但有时需要提供独立的Java API。一种感受你的库中的Java API好的方式是用Java写单元测试(只是为了兼容性);这也确保了你的库中的Java视图保持稳定，在这一点上不会随着时间因Scala编译器的波动而影响。

包含部分实现的Trait不能直接被Java使用： 改为 extends 一个抽象类

 // 不能直接被java使用
 trait Animal {
   def eat(other: Animal)
   def eatMany(animals: Seq[Animal) = animals foreach(eat(_))
 }

 // 改为这样:
 abstract class JavaAnimal extends Animal

Twitter标准库

Future

Futures已经在并发一节中简单讨论过。它是调异步处理的中心机制，渗透在我们代码库中，也是Finagle的核心。Futures允许组合并发事件，简化了高并发操作。也是JVM上异步并发的一种高效的实现。

Twitter的future是异步的，所以基本上任何操作(阻塞操作)——基本上任何可以suspend它的线程的执行；网络IO和磁盘IO是就是例子——必须由系统处理，它为结果提供future。Finagle为网络IO提供了这样一种系统。

Futures清晰简单：它们持有一个尚未完成运算结果的 promise 。它们是一个简单的容器——一个占位符。一次计算当然可能会失败，这种状况必须被编码：一个Future可以是三种状态之一： pending, failed, completed。

val f = (i: Int) => i.toString
val g = (s: String) => s+s+s
val h = g compose f  // : Int => String
    
scala> h(123)
res0: java.lang.String = 123123123

Futures是一种集合类型——它是个包含0或1个元素的容器——你可以发现他们有标准的集合方法（eg：map, filter, foreach）。因为Future的值是延迟的，结果应用这些方法中的任何一种必然也延迟；在

 val result: Future[Int]
 val resultStr: Future[String] = result map { i => i.toString }

函数 { i => i.toString } 不会被调用，直到int值可用；转换集合的resultStr在可用之前也一直是待定状态。

List可以被扁平化(flattened)：

 val listOfList: List[List[Int]] = ..
 val list: List[Int] = listOfList.flatten

这对future也是有意义的：

 val futureOfFuture: Future[Future[Int]] = ..
 val future: Future[Int] = futureOfFuture.flatten

因为future是延迟的，flatten的实现——立即返回——不得不返回一个等待外部future (Future[Future[Int]]) 完成的future (Future[Future[Int]]).如果外部future失败，内部flattened future也将失败。

Future (类似List) 也定义了flatMap；Future[A] 定义方法flatMap的签名

 flatMap[B](f: A => Future[B]): Future[B]

如同组合 map 和 flatten，我们可以这样实现：

 def flatMap[B](f: A => Future[B]): Future[B] = {
   val mapped: Future[Future[B]] = this map f
   val flattened: Future[B] = mapped.flatten
   flattened
 }

这是一种有威力的组合！使用flatMap我们可以定义一个 Future 作为两个Future序列的结果。第二个future 的计算基于第一个的结果。想象我们需要2次RPC调用来验证一个用户身份，我们可以用下面的方式组合操作：

 def getUser(id: Int): Future[User]
 def authenticate(user: User): Future[Boolean]

 def isIdAuthed(id: Int): Future[Boolean] =
   getUser(id) flatMap { user => authenticate(user) }

这种组合类型的一个额外的好处是错误处理是内置的：如果getUser(..)或authenticate(..)失败，future 从 isAuthred(..)返回时将会失败。这里我们没有额外的错误处理的代码。

风格

Future回调方法(respond, onSuccess, onFailure, ensure) 返回一个新的Future，并链接到调用者。这个Future被保证只有在它调用者完成后才完成，使用模式如下：

 acquireResource()
 future onSuccess { value =>
   computeSomething(value)
 } ensure {
   freeResource()
 }

freeResource() 被保证只有在 computeSomething之后才执行，这样就模拟了try-finally 模式。

使用 onSuccess替代 foreach —— 它与 onFailure 方法对称，命名的意图更明确，并且也允许 chaining。

永远避免直接创建Promise实例： 几乎每一个任务都可以通过使用预定义的组合子完成。这些组合子确保错误和取消是可传播的, 通常鼓励的数据流风格的编程，不再需要同步和volatility声明。

用尾递归风格编写的代码不再导致堆栈空间泄漏，并使得以数据流风格高效的实现循环成为可能：

 case class Node(parent: Option[Node], ...)
 def getNode(id: Int): Future[Node] = ...

 def getHierarchy(id: Int, nodes: List[Node] = Nil): Future[Node] =
   getNode(id) flatMap {
     case n@Node(Some(parent), ..) => getHierarchy(parent, n :: nodes)
     case n => Future.value((n :: nodes).reverse)
   }

Future定义很多有用的方法： 使用 Future.value() 和 Future.exception() 来创建未满意(pre-satisfied) 的future。Future.collect(), Future.join() 和 Future.select() 提供了组合子将多个future合成一个(例如：scatter-gather操作的gather部分)。

Cancellation

Future实现了一种弱形式的取消。调用Future#cancel 不会直接终止运算，而是发送某个级别的可被任何处理查询的触发信号，最终满足这个future。Cancellation信号流向相反的方向：一个由消费者设置的cancellation信号，会传播到它的生产者。生产者使用 Promise的onCancellation来监听信号并执行相应的动作。

这意味这cancellation语意上依赖生产者，没有默认的实现。cancellation只是一个提示。

Local

Offer/Broker

致谢

本课程由Twitter公司Scala社区贡献——我希望我是个忠实的记录者。

Blake Matheny, Nick Kallen, Steve Gury, 和Raghavendra Prabhu提供了很多有用的指导和许多优秀的建议。