Effective Scala

序章

書式

コードの書式の細かい話は（それが実践的である限りは）重要ではない。当然だが、スタイルに本質的な良し悪しはないし、個人的な好みはほぼ人によって異なる。しかし、同じ整形ルールを一貫して適用すれば、ほとんどの場合で可読性が高まる。特定のスタイルに馴染んだ読み手は、さらに別のローカルな慣習を把握したり、言語の文法の隅を解読したりする必要がない。

これは、重複度の高い文法を持つ Scala においては特に重要だ。メソッド呼び出しは分かりやすい例だ: メソッドは “.” を付けても、ホワイトスペースで空けても呼び出せる。同様に、ゼロまたは一つ引数を取るメソッドでは、丸カッコを付けても良いし付けなくても良い、といった様に。さらに、メソッド呼び出しの様々なスタイルは、文法上の様々な曖昧さをさらけ出す！ 注意深く選ばれた整形ルールを一貫して適用することで、人間と機械の両方にとっての多くの曖昧さを解決できるのは間違いない。

ホワイトスペース

インデントは、スペース 2 つとする。100 カラムを超える行は避ける。メソッド、クラス、オブジェクトの定義同士の間に一行空ける。

命名

小さいスコープでは短い名前を使う

ループ内では i, j, k が期待される。

より大きいスコープでは、より長い名前を使う

外部APIは、より長く、説明的で意味付けされた名前を持つべきだ。例えば、Future.all ではなく Future.collect とした方がよい。

一般的な略語を使い、難解な略語を避ける

ok や err や defn は誰もが知っている。しかし sfri はそれほど一般的ではない。

異なる用途に名前を再利用しない

val を使おう。

予約名を ` でオーバーロードするのは避ける

`type` ではなく typ とする。

副作用を起こす操作は能動態で命名する

user.setActive() ではなく user.activate() とする。

値を返すメソッドは説明的に命名する

src.defined ではなく src.isDefined とする。

ゲッター (getter) の名前の先頭に get を付けない

以前のルールと同様にこれは冗長だ。site.getCount ではなく site.count とする。

パッケージ名やオブジェクト名で既にカプセル化されている名前を繰り返さない

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

ではなく

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

とする。User.getUser は冗長だし、User.get よりも多くの情報を与えない。

インポート

import 行はアルファベット順に並べ替える

こうすると視覚的に調べやすいし自動化もしやすい。

パッケージから複数の名前をインポートする際は中カッコを使う

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

6 個以上の名前をインポートする際はワイルドカードを使う

例: import com.twitter.concurrent._
ワイルドカードを濫用しないこと。一部のパッケージは大量の名前をエクスポートする。

コレクションを使う際は、scala.collection.immutable と scala.collection.mutable の一方あるいは両方をインポートして名前を修飾する

可変 (mutable) コレクションと不変 (immutable) コレクションでは名前が重複している。名前を修飾して、どちらのコレクションを使っているか読み手に対して明らかにしよう。 (例: "immutable.Map")

他のパッケージからの相対指定でインポートしない

import com.twitter
import concurrent

とは書かずに曖昧さの無い書き方をしよう。

import com.twitter.concurrent

import 文はファイルの先頭に置く

全ての import を読み手が一箇所で参照できるようにしよう。

中カッコ

中カッコは複合式を作るのに使われる（“モジュール言語”では他の用途にも使われる）。このとき、複合式の値はリスト中の最後の式だ。単純な式に中カッコを使うのはやめよう。

def square(x: Int) = x*x

と書く代わりに、メソッドの本体を構文的に見分けられるように

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

と書きたくなるかもしれない。しかし、最初の方がゴチャゴチャしていなくて読みやすい。明確化が目的でないなら仰々しい構文を使うのはやめよう。

パターンマッチ

関数定義の中で、パターンマッチを直接使える場合はいつでもそうしよう。

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

という間接的な書き方では意図がはっきりしない。代わりに match を折り畳んで

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

と書くと、リストの要素を写像 (map over) していることが分かりやすい。

コメント

型とジェネリクス

型システム (type system) の主な目的は、プログラミングの誤りを検出することだ。型システムは、制限された静的検査を効果的に提供する。これを使うと、コードについてある種の不変条件 (invariant) を記述して、それをコンパイラで検証できる。型システムがもたらす恩恵はもちろん他にもあるが、エラーチェックこそ、その存在理由（レーゾンデートル）だ。

我々が型システムを使う場合はこの目的を踏まえるべきだが、一方で、読み手にも気を配り続ける必要がある。型を慎重に使ったコードは明瞭さが高まるが、過剰に巧妙に使ったコードは読みにくいだけだ。

戻り型アノテーション

Scala では戻り型アノテーション (return type annotation) を省略できるが、一方でアノテーションは優れたドキュメンテーションを提供する。特に、public メソッドにとっては重要だ。戻り型が明白で露出していないメソッドの場合は省略しよう。

これは、ミックスインを使ったオブジェクトのインスタンス化において、Scala コンパイラがシングルトン型を生成する際に特に重要だ。例えば、make 関数が:

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

Service という戻り型を持たない場合、コンパイラは細別型 (refinement type) の Object with Service{def getId: Int} を生成する。代わりに、明示的なアノテーションを使うと:

def make(): Service = new Service{}

make の公開する型を変更することなく、トレイトをさらに好きなだけミックスできる。つまり、後方互換性の管理が容易になる。

変位

変位 (variance) は、ジェネリクスが派生型 (subtyping) と結びつく際に現れる。変位は、コンテナ型 (container type) の派生型と、要素型 (contained type) の派生型がどう関連するかを定義する。Scala では変位アノテーションを宣言できるので、コレクションに代表される共通ライブラリの作者は、多数のアノテーションを扱う必要がある。変位アノテーションは共有コードの使い勝手にとって重要だが、誤用すると危険なものになりうる。

非変 (invariant) は高度だが、Scala の型システムにとって必須の特徴であり、派生型の適用を助けるために広く（そして正しく）使われるべきだ。

不変コレクションは共変 (covariant) であるべきだ。要素型を受け取るメソッドは、コレクションを適切に“格下げ”すべきだ:

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

可変コレクションは非変であるべきだ。共変は、通常は可変コレクションにおいては無効だ。この

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

と、以下の型階層について考えてみよう:

trait Mammal
trait Dog extends Mammal
trait Cat extends Mammal

もしここに犬 (Dog) のハッシュセットがあるなら、

val dogs: HashSet[Dog]

それを哺乳類 (Mammal) の集合として扱ったり、猫 (Cat) を追加したりできる。

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

これはもはや、犬の HashSet ではない！

型エイリアス

型エイリアス (type alias) を使うと、便利な名前を提供したり、意味を明瞭にしたりできる。しかし、一目瞭然な型をエイリアスすべきではない。

() => Int

は、短くて一般的な型を使っているので、

type IntMaker = () => Int
IntMaker

よりも意味が明瞭だ。しかし、

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

は、意思疎通が目的で簡潔さを高めたい場合に有用だ。

エイリアスが使える場合は、サブクラスにしてはいけない。

trait SocketFactory extends (SocketAddress => Socket)

SocketFactory は Socket を生成する関数だが、型エイリアス

type SocketFactory = SocketAddress => Socket

を使う方がいい。これで、SocketFactory 型の値となる関数リテラルが提供されるので、関数合成が使える:

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

val factory: SocketFactory = addrToInet andThen inetToSocket

パッケージオブジェクトを使うと、型エイリアスをトップレベル名として束縛できる:

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

型エイリアスは新しい型ではないことに注意しよう。型エイリアスは、エイリアスされた名前をその型へと構文的に置換することと同等だ。

暗黙

暗黙 (implicit) は強力な型システムの機能だが、慎重に使うべきだ。それらの解決ルールは複雑で、シンプルな字句検査においてさえ、実際に何が起きているか把握するのを困難にする。暗黙を間違いなく使ってもいいのは以下の状況だ:

コレクション

階層

Scala のコレクションライブラリは巨大だ。Traversable[T] を基底とする入り組んだ継承階層だけでなく、ほとんどのコレクションに immutable 版と mutable 版がある。どんなに複雑でも、以下の図は immutable と mutable の双方の階層にとって重要な区別を含んでいる。

Iterable[T] はイテレート (iterate) できるコレクションで、iterator (と foreach) メソッドを提供する。Seq[T] は順序付けされたコレクション、Set[T] は数学的集合（要素が一意な順序付けのないコレクション）、そして Map[T] は順序付けのない連想配列だ。

使う

不変 (immutable) コレクションを使おう。不変コレクションはほとんどの状況に適用できる。また、不変コレクションは参照透過なのでデフォルトでスレッドセーフとなり、プログラムの理解が容易になる。

明示的に mutable 名前空間を使おう。scala.collections.mutable._ を import して Set を参照するのではなく、

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

とすることで、可変版の `Set` が使われていることがはっきりする。

コレクション型のデフォルトコンストラクタを使おう。例えば、順序付きの（かつ連結リストである必要がない）シーケンスが必要な場合は、いつでも Seq() コンストラクタを使おう:

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

スタイル

関数型プログラミングでは、パイプライン化した不変コレクションの変換によって、コレクションを望みの結果へと成形することが推奨されている。この手法により、多くの問題をとても簡潔に解決できるが、これは読み手を困惑させる可能性がある。パイプライン化した変換は時に作者の意図の理解を困難にするので、その場合、暗黙的に示される中間結果を全て追跡し続けるしかない。例えば、様々なプログラミング言語に対する投票である (language, num votes) のシーケンスを集計して、票数が最も多い言語から順番に表示するコードは以下のように書ける:

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 = ...
  ...
}

性能

高水準コレクションライブラリは（高水準な構築物が一般的にそうであるように）性能の推測が難しい。コンピュータに直接指示する”命令型スタイル”から遠ざかるほど、あるコード片が性能に与える影響を厳密に予測するのは困難になる。一方で、コードの正確さを判断するのは概して容易だし、読みやすさも高まる。Scala の場合、Java ランタイムが事態をさらに複雑にしている。Scala はユーザに対してボクシング (boxing) およびアンボクシング (unboxing) 操作を隠蔽するので、性能やメモリ使用量の面で重大なペナルティを被ることがある。

Java コレクション

Java コレクションと Scala コレクションと相互運用するには、scala.collection.JavaConverters を使おう。JavaConverters は、暗黙変換を行う 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

並行性

現代のサービスは高い並行性 (concurrency) を備え、サーバが何万何十万もの同時操作をコーディネートするのが一般的になっている。そして、堅固なシステムソフトウェアを記述する上で、暗黙的な複雑性への対処は中心的なテーマだ。

スレッド (thread) は、並行性を表現する手段の一つだ。スレッドを使うことで、オペレーティングシステムによってスケジュールされる、ヒープを共有する独立した実行コンテクストを利用できる。しかし、Java においてスレッド生成はコストが高いので、典型的にはスレッドプールを使うことで、スレッドをリソースとして管理する必要がある。これは、プログラマにとってさらなる複雑さと高い結合度を生み出す。つまり、アプリケーションロジックと、それが使用する潜在的なリソースを分離するのが難しくなる。

この複雑さは、出力 (fan-out) の大きいサービスを作成する際に、とりわけ明らかになる。それぞれの受信リクエストからは、システムのさらに別の階層に対する多数のリクエストが生じる。それらのシステムにおいて、スレッドプールは各階層でのリクエストの割合によってバランスを保つように管理される必要がある。あるスレッドプールで管理に失敗すると、その影響は他のスレッドプールにも広がってしまう。

また、堅固なシステムはタイムアウトとキャンセルについても検討する必要がある。どちらに対処するにも、さらなる”制御スレッド”を導入する必要があるので、問題がさらに複雑になる。ちなみに、もしスレッドのコストが安いなら問題は低減できる。スレッドプールが必要なくなり、タイムアウトしたスレッドを放棄することができ、追加のリソース管理も必要ないからだ。

このように、リソース管理はモジュール性を危うくするのだ。

Future

コレクション

並行コレクションの話題は、私見と、機微と、ドグマと、FUD に満ちている。それらは、大抵の実践的な状況においては取るに足らない問題だ: 目的を果たすためには、いつでも最も単純で、最も退屈で、最も標準的なコレクションから始めよう。同期化コレクションでは上手くいかないことが分かる前に、並行コレクションを手に取ってはいけない。JVM は、同期を低コストで実現する洗練された機構を持っている。その効率に君は驚くだろう。

不変 (immutable) コレクションで目的を果たせるなら、それを使おう。不変コレクションは参照透過なので、並行コンテキストでの推論が簡単になる。不変コレクションの変更は、主に（var セルや AtomicReference が指す）現在の値への参照を更新することで行う。不変コレクションの変更は注意が必要だ。他のスレッドへ不変コレクションを公開するには、AtomicReference は再試行が必要だし、var 変数は volatile として宣言しなければならない。

可変 (mutable) な並行コレクションは複雑な動作をするだけでなく、Java メモリモデルの微妙な部分を利用するので、特に更新を公開する方法などの暗黙的な挙動を理解しておこう。同期化コレクションの方が合成は簡単だ。並行コレクションでは getOrElseUpdate のような操作を正しく実装できないし、特に並行コレクションの合成はエラーの温床になる。

制御構造

関数型スタイルのプログラムは、従来の制御構造が少なくなり、また、宣言型スタイルで書かれていると読みやすいことが多い。こうしたスタイルでは、典型的にはロジックをいくつかの小さなメソッドや関数に分解し、それらを互いに match 式で貼り合わせる。また、関数型プログラムは、より式指向となる傾向がある: つまり、条件式のそれぞれの分岐は同じ型の値を計算し、for (..) yield は内包 (comprehension) を計算する。また、再帰の利用が一般的だ。

再帰

再帰表現を使うと、問題をしばしば簡潔に記述できる。そしてコンパイラは、末尾呼び出しの最適化が適用できるコードを正規のループに置き換える（末尾最適化が適用されるかは @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 によって早期に終了する。

return を使うと、分岐を減らして不変式 (invariant) を定めることができる。これにより、入れ子が減ってコードを追いやすくなるだけでなく、後続のコードの正当性を推論しやすくなる（配列の範囲外をアクセスしないことを確認する場合とか）。これは、“ガード”節で特に有用だ:

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 を使って、コードを明快にして読みやすさを高めよう。ただし、命令型言語でのような使い方をしてはいけない。つまり、計算結果を返すために 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"
}

と書く代わりに下記のように書こう:

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

しかし、match 式を使うのがより優れた方法だ:

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...
}

この `return` は、バイトコードでは例外を `throw` と `catch` するコードとして実装されるので、実行頻度の高いコード内で使うと性能に影響を与える。

forループと内包

for を使うと、ループと集約を簡潔かつ自然に表現できる。for は、多数のシーケンスを平坦化 (flatten) する場合に特に有用だ。for の構文は、内部的にはクロージャを割り当ててディスパッチしていることを覆い隠している。これにより予期しないコストが発生したり、予想外の挙動を示したりする。例えば、

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

このコードは `container` が遅延評価されるとランタイムエラーが発生し、これにより return が非局所的 (nonlocal) に評価されてしまう！

これらの理由から、コードを明瞭にするためである場合を除いて、for の代わりに foreach, flatMap, map, filter を直接呼び出すのが良いことが多い。

（訳者による補足: Scala の for 式は `foreach`, `flatMap`, `map`, `withFilter` を呼び出す糖衣構文で、ループ内の式は、コンパイル時にそれらのメソッドに渡される匿名関数に変換される。例えば、上記の for 式は:

container foreach { item =>
  if (item != 2) return
}

というコードとして実行される。本ガイドでは、最初からこのように記述することを推奨している。

require と assert

require と assert は、どちらも実行可能なドキュメントとして機能する。これらは、型システムが要求される不変条件 (invariant) を表現できない状況で有用だ。assert は、コードが仮定する（内部あるいは外部の）不変条件を表現するために使われる。例えば、

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

一方で、require は API の契約を表現するために使われる:

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

関数型プログラミング

値指向プログラミングは、特に関数型プログラミングと一緒に用いることで数々の利益をもたらす。このスタイルはステートフルな変更よりも値の変換を重視し、参照透過 (referentially transparent) なコードを生み出し、より強力な不変式 (invariant) を提供するので、推論が容易になる。ケースクラス、パターンマッチ、構造化代入 (destructuring binding) 、型推論、クロージャやメソッドの軽量な生成構文がこの仕事の道具になる。

代数的データ型としてのケースクラス

ケースクラス (case class) は、代数的データ型 (algebraic data type) をエンコードする: ケースクラスは数多くのデータ構造をモデリングするのに役に立ち、強力な不変式を簡潔なコードとして提供する。ケースクラスは、パターンマッチと共に利用すると特に有用だ。パターンマッチの解析器は、さらに強力な静的保証を提供する包括的解析 (exhaustivity analysis) を実装している。

ケースクラスで代数的データ型をエンコードする際は、以下のパターンを使おう:

sealed trait Tree[T]
case class Node[T](left: Tree[T], right: Tree[T]) extends Tree[T]
case class Leaf[T](value: T) extends Tree[T]

Tree[T] 型には Node と Leaf の 2 つのコンストラクタがある。型を sealed として宣言するとソースファイルの外でコンストラクタを追加できなくなるので、コンパイラに包括的解析を行わせることができる。

パターンマッチと共に使うと、上記のモデリングは簡潔でありかつ”明らかに正しい”コードになる:

def findMin[T <: Ordered[T]](tree: Tree[T]) = tree match {
  case Node(left, right) => Seq(findMin(left), findMin(right)).min
  case Leaf(value) => value
}

木構造のような再帰的構造は、代数的データ型の古典的な応用を占めるが、代数的データ型が有用な領域はそれよりずっと大きい。特に、状態機械によく現れる直和 (disjoint union) は、代数的データ型で容易にモデル化できる。

Option

Option 型は、空の状態 (None) と満たされた状態 (Some(value)) のいずれかであるコンテナだ。Option は null の安全な代替手段を提供するので、いつでも可能な限り利用するべきだ。Option は（たかだか要素が一つの）コレクションなので、コレクション操作を利用できる。使うしかない!

以下のように書くのは安全ではない:

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

以下のように書こう:

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

Option 型は、username が空であるかのチェックを静的に強制してくれるのでより安全だ。

Option 値の条件実行は foreach を使うべきだ。以下のように書く代わりに:

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

以下のように書こう:

opt foreach { value =>
  operate(value)
}

このスタイルは奇妙に思えるかもしれないが、より優れた安全性と簡潔さを提供する（例外を引き起こしうる get は呼んでいない）。空の場合と値を持つ場合の両方の分岐がありうるなら、パターンマッチを使おう:

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

しかし、もし値がない場合にデフォルト値で良いなら getOrElse がある。

operate(opt getOrElse defaultValue)

パターンマッチ

パターンマッチ (x match { ...) は、うまく書かれた Scala コードのあらゆる場所で使われる。パターンマッチは、条件実行と分解、そして一つの構成物へのキャストの 3 つを融合する。うまく使うことで明快さと安全性の双方を高められる。

型ごとに処理を切り替える実装にパターンマッチを使う:

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

また、パターンマッチは分解と組み合わせることで最も良い働きを示す。ケースクラスにマッチする際は、以下のように書かずに:

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]

なぜなら、PartialFunction の組み合わせ可能な性質を大いに活かせるからだ:

val classifier1: Classifier
val classifier2: Classifier

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

構造化代入

遅延評価

Scala において、lazy で修飾された val フィールド（遅延フィールド）は必要になったときに計算される。なぜなら、Scala ではフィールドとメソッドは等価だからだ（Scala のフィールドを Java のフィールドと同じものにしたい場合は private[this] を使う）。

lazy val field = computation()

は（おおよそ）以下のようなコードの簡易記法だ:

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

すなわち、計算して結果を記憶する。遅延フィールドは、この目的のために使うようにする。しかし、意味論によって遅延を要求される場合に遅延評価を使うべきではない。このような場合には明示的に書いた方がよい。なぜなら、それによりコストモデルが明確になり、副作用をより精密に制御できるからだ。

遅延フィールドはスレッドセーフだ。

名前呼び出し

メソッドの引数は、名前によって特定してもよい。その意味は、引数を値ではなく、繰り返し評価されうる計算に対して束縛するということだ。値渡しの文脈を期待している呼び出し側を驚かせないように、この機能は注意深く適用すべきだ。この機能の目的は、構文的に自然な DSL を構築することにある。特に、新しい制御構造を、あたかも最初から言語に備わっている機能であるかのように見せることができる。

名前呼び出し (call-by-name) は、そのような制御構造に渡されるのが、呼び出し側にとって思いもよらない計算の結果ではなく”ブロック”であることが明らかな場合にのみ使おう。同様に、名前呼び出しの引数は、最後の引数リストの最後の位置でのみ使うべきだ。引数が名前呼び出しであるメソッドの名前は、呼び出し側にそのことが分かるように命名しよう。

値を複数回計算させたくて、特にその計算が副作用を持つなら明示的な関数を使おう:

class SSLConnector(mkEngine: () => SSLEngine)

提供者の意図はシグネチャから明らかであり、呼び出し側を驚かせることがない。

flatMap

flatMap は map と flatten を組み合わせたもので、その巧妙な力と素晴らしい実用性によって特別な注目を浴びるに値する。flatMap は、その仲間の map と同様に、Future や Option のような従来とは異なるコレクションにおいてもしばしば利用可能だ。その振る舞いはシグネチャから明らかだ。ある Container[A] について、

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

flatMap はコレクションの要素に対し、各要素から新しいコレクションを作り出す関数 f を呼び出した後、その生成した（全ての）コレクションを平坦化 (flatten) した結果を返す。例えば、同じ文字を繰り返さないような 2 文字の文字列の順列を全て取得するには:

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 内包記法と（おおよそ）等価だ:

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

flatMap は Option を扱う際にしばしば有用だ。flatMap を使うと、Option の連鎖を畳み込んで一つにできる。

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 にはミックスイン (mixin) の機能もある。ミックスインを使うと、もっと直交的かつ段階的にモジュールを組み合わせられるだけでなく、そこにコンパイル時の静的な型検査を柔軟に組み合わせて、その恩恵をすべて享受できる。

依存性注入

しかし、Scala 自身が、”古典的な”（コンストラクタへの）依存性注入を利用する際の面倒な構文を、ほとんど取り除いてくれることが分かったので、Twitter ではむしろ依存性注入を使うようにしている: それはより明快で、依存性はやはり（コンストラクタの）型によってエンコードされ、クラスを構築する構文はとりたてて難しくなく扱いやすい。それは退屈で単純だが、うまくいく。依存性注入はプログラムをモジュール化するために使おう。そして、特に継承より合成を使おう。これにより、よりモジュール化されてテストが容易なプログラムになる。継承が必要な状況に遭遇したら、こう考えてみよう: ”もし継承をサポートしない言語を使うとしたら、このプログラムをどのように構造化するだろう？”と。その答えには説得力があるかもしれない。

通常、依存性注入にはトレイトを使う。

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

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

一般的には、注入するのは他のオブジェクトを生成するオブジェクトであるファクトリ (factory) だ。この場合、特化したファクトリ型ではなくシンプルな関数を使うべきだ。（訳者による補足: つまり、戻り値を持つあらゆる関数はファクトリとみなせるということ）

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

トレイト

依存性注入を使用するからといって、共通のインタフェースや、トレイト (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])
 }

そして、これらを互いに new Reader with Writer… のようにミックスインして、先ほどの IOer を形成する。インターフェイスの最小化は、よりよい直交性とモジュール化をもたらす。

可視性

Scala は、可視性を制御するための非常に表現力の高い修飾子を持つ。これらの修飾子は、何を公開 API として構成するかを定義するのに使うので重要だ。公開する API は限定されるべきだ。それによってユーザが実装の詳細にうっかり依存することがなくなり、また、作者が API を変更する能力を制限する。これらは、良いモジュール性にとって極めて重要だ。原則的に、公開 API を拡張するのは縮小するよりもはるかに簡単だ。また、アノテーションが貧弱だと、コードのバイナリの後方互換性が危うくなる。

private[this]

private に指定したクラスメンバは、

 private val x: Int = ...

そのクラス（サブクラスは除く）の全てのインスタンスから可視になる。ほとんどの場合、private[this] としたいだろう。

 private[this] val x: Int = ...

これで x の可視性は特定のインスタンスに制限される。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) を見ることになる。

構造的部分型

エラー処理

Scala は例外機能を提供するが、正確さのためにプログラマが適切に対処すべき場合に、これを一般的なエラーに対して使ってはいけない。代わりに Option や com.twitter.util.Try を使うのは、慣習的で良い選択だ。これらは、型システムを利用して、ユーザがエラー処理を適切に考慮するようにする。

例えば、レポジトリを設計する時に、以下のような API にしたくなるかもしれない:

trait Repository[Key, Value] {
  def get(key: Key): Value
}

しかし、これを実装すると key が存在しない時に例外を投げる必要がある。より良いやり方は Option を使うことだ:

trait Repository[Key, Value] {
  def get(key: Key): Option[Value]
}

このインタフェースなら、レポジトリがあらゆる key を含まなくてもよく、またプログラマが key が見つからない場合に対処しなければならないことが明確になる。さらに、Option はこうしたケースに対処するための数多くのコンビネータを備えている。例えば、getOrElse は key が見つからない場合にデフォルト値を供給するのに使われる:

val repo: Repository[Int, String]
repo.get(123) getOrElse "defaultString"

例外処理

Scala の例外機構は非チェック例外、つまりプログラマが可能性のある例外をカバーしているかをコンパイラが静的にチェックできないので、例外処理において広い網をかけたくなりがちだ。

しかし、いくつかの fatal（致命的）な例外は捕捉 (catch) するべきではない。

However, some exceptions are fatal and should never be caught; the code

try {
  operation()
} catch {
  case _ => ...
}

このコードは伝搬するべき致命的なエラーを捕捉してしまうので、ほとんどの場合で誤りだ。代わりに、非致命的な例外のみを捕捉する com.twitter.util.NonFatal 抽出子を使う。

try {
  operation()
} catch {
  case NonFatal(exc) => ...
}

ガベージコレクション

Twitter では、実運用において多くの時間をガベージコレクションのチューニングに費している。ガベージコレクションにおける関心事は Java のそれとほとんど同じだが、関数型スタイルの副作用として、慣習的な Scala コードは Java よりも多くの（生存期間の短い）ガベージを生成する。HotSpot の世代別ガベージコレクションは、生存期間の短いガベージを効率的に解放するので、ほとんどの状況ではこれは問題にならない。

Java との互換性

Twitter では、Java から使われるコードを Scala で書くとき、Java での慣習的な使い方ができるようにしている。多くの場合、追加の努力は必要ない。クラスと純粋な（実装を含まない）トレイトは、Java において対応するものと正確に同じものになる。しかし、時々、別個の Java API を提供する必要がある。ライブラリの Java API の感じをつかむ良い方法は、Java で単体テストを書くことだ（コンパイルが通れば良い）。このテストによってライブラリの Java ビューが安定していることが保証されるので、将来、Scala コンパイラが生成する実装が変化しても検出できる。

実装を含むトレイトは直接 Java から利用できない。代わりに、抽象クラスをトレイトと共に拡張する。

 // 直接 Java からは利用できない
 trait Animal {
   def eat(other: Animal)
   def eatMany(animals: Seq[Animal) = animals foreach(eat(_))
 }

 // しかし、これなら利用できる
 abstract class JavaAnimal extends Animal

Twitterの標準ライブラリ

Future

Offer と Broker

謝辞

本レッスンは、Twitter 社の Scala コミュニティによるものだ。私は誠実な記録者でありたい。

Blake Matheny と Nick Kallen、Steve Gury、そして Raghavendra Prabhu には、とても有益な助言と多くの優れた提案を与えてもらった。

日本語版への謝辞