Effective Scala

Введение

Форматирование

Специфические способы форматирования кода - пока они полезны - не имеют большого значения. По определению, стиль не может быть хорошим или плохим, почти все определяет личное предпочтение. Однако, последовательное применение одних и тех же правил форматирования будет почти всегда увеличивать удобочитаемость. Читатель, уже знакомый с данным стилем, не должен разбираться в еще одном наборе местных соглашений или расшифровать еще одну часть языковой грамматики.

Это имеет особое значение для Scala, поскольку у его грамматики высокий уровень вхождения. Один говорящий пример - вызов метода: Методы могут быть вызваны с помощью “.”, либо с использованием пробела, либо без круглой скобки для не методов, не возвращающих значений, или для унарных методов, с круглой скобкой для этих же случаев, и так далее. Кроме того, различные стили вызова методов оставляют двусмысленность в его грамматике! Конечно, последовательное применение заранее определенного набора правил форматирования решит большую часть двусмысленности и для человека, и для машины.

Мы придерживаемся [Правила форматирования в языке Scala] (http://docs.scala-lang.org/style/) и дополнительно следующих правил.

Пробельные символы

При отступе используется 2 пробельных символа. Мы стараемся избегать строк, длиной более 100 символов. Мы используем одну пустую строку между методом, классом и определениями объекта.

Именование

Используйте короткие имена для небольших областей видимости

Применяйте i,j и k и тому подобные переменные в циклах

Используйте длинные имена для больших областей видимости

Внешние API должны иметь длинные и понятные имена, которые придают смысл. Future.collect вместо Future.all.

Используйте стандартные сокращения, и откажитесь от эзотерических

Всем известны ok, err или defn,а вот sfri используется не так часто.

Не используйте одни и те же имена для различных целей

Применяйте val

Избегайте использования ` для перегрузки зарезервированных имен.

Используйте typ вместо `type`

Используйте в имени active для операций с побочными эффектами

user.activate() вместо user.setActive()

Используйте описательные имена для методов, которые возвращают значения

src.isDefined вместо src.defined

Не используйте у геттеров(getter) префикс get

В соответствии с предыдущим правилом: лучше применять site.count вместо site.getCount

Не используйте повторно имена, которые уже есть в пакете или в названии объекта

Предпочтительно:

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

вместо

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

Они являются избыточными, так как при использовании: User.getUser дает не больше информации, чем User.get.

Импорт

Располагайте строки импорта в алфавитном порядке

Так их проще определить визуально, и так проще для автоматизации.

Используйте фигурные скобки при импортировании нескольких имен из пакета

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

Используйте символ подчеркивания, когда импортируйте более 6 имен

например: import com.twitter.concurrent._
Не применяйте этот знак без оглядки, некоторые пакеты экспортируют слишком много имен

Когда используете коллекции, уточняйте имена при импортировании scala.collection.immutable и/или scala.collection.mutable

Изменяемые и неизменяемые коллекции имеют двойные имена. Уточнение имен сделает очевидным для читателя, какой вариант используется (например "immutable.Map")

Не используйте относительный импорт из других пакетов

Избегайте

import com.twitter
import concurrent

в пользу более одназначного

import com.twitter.concurrent

Располагайте строки импорта вверху файла

Читатель может обратиться ко всем строкам импорта в одном месте

Фигурные скобки

Фигурные скобки используются для создания сложных выражений (они служат другим целям в “module language”), где значение соответствующего выражения является последним выражением в списке. Старайтесь не использовать скобки для простых выражений; пишите

def square(х: Int) = х*х

.LP, вместо

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

.LP, хотя это может быть привлекательным, чтобы отличить тело метода синтаксически. Первый вариант имеет меньший беспорядок, и его легче читать. Избегайте лишних синтаксических конструкций, если это не уточняется дополнительно.

Сравнение с образцом

Используйте сравнение с образцом в определении функций, когда это необходимо; Вместо

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

лучше написать так

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

Видно, что элементы списка сейчас отображаются более ясно — дополнительно уточнять ничего не нужно.

Комментарии

Типы и обобщенные типы

Основной целью системы типов является выявление ошибок программирования. Система типов эффективно обеспечивает определенную форму статической проверки, что позволяет нам получать определенный набор неизменных параметров о нашем коде, который компилятор может проверить. Система типов, конечно, обеспечивает и другие преимущества, но проверка ошибок является ее основной целью.

Использование системы типов должно отражать эту цель, но мы должны не забывать и о читателе: разумное использование типов может служить повышением ясности. Все слишком усложнять - значит запутывать остальных.

Мощная система типов в Scala является результатом общих усилий различных академических опытов и разработок (например, [Scala программирование на уровне системы типов] (http://apocalisp.wordpress.com/2010/06/08/type-level-programming-in-scala/)). Несмотря на то, что это увлекательная академическая статья, эти методы редко находят полезное применение в реальном коде приложений. Их можно избегать.

Возвращаемый тип аннотаций

Хотя Scala позволяет опускать их, такие аннотации обеспечивают хорошую документацию: это особенно важно для публичных методов. Там где возвращаемый тип метода очевиден, их можно опустить.

Это особенно важно при создании экземпляров объектов с миксинами(Mixins), так как компилятор Scala создает тип синглтон(singleton) для них. Например, make в примере:

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

не имеет возвращаемого типа Service; компилятор создает Object with Service{def getId: Int}. Вместо того, чтобы использовать явную аннотацию:

def make(): Service = new Service{}

В настоящее время автор может смешивать множество трейтов(traits) без изменения общедоступного типа make, делая возможность легче управлять обратной совместимостью.

Расхождение

Расхождение возникает, когда обобщенные типы объединены с выделением подтипов. Они определяют, как выделение подтипов типа contained относится к выделению подтипов типа container. Поскольку в Scala имеется определенное соглашение по комментированию, то авторы общих библиотек - особенно коллекций - должны активно писать комментарии. Такие комментарии важны для удобства работы с общим кодом, но неверные комментарии могут быть опасны.

Инварианты - усовершенствованный, но необходимый компонент системы типов Scala, и должны использоваться широко (и правильно), поскольку это помогает приложению в выделении подтипов.

Коллекции Immutable должны быть ковариантны. Методы, которые получают contained тип должны быть “понижены”(“downgrade”) до соответствующей коллекции:

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

Mutable коллекции должны быть инвариантны. Ковариация обычно бессмысленна с изменяемыми(mutable) коллекциями. Рассмотрим

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

и следующую иерархию типов:

trait Mammal
trait Dog extends Mammal
trait Cat extends Mammal

Допустим, у нас сейчас есть хеш-коллекция из объектов Собака

val dogs: HashSet[Dog]

создаем хеш-коллекцию Млекопитающих и добавляем в колллекцию объект Кошка

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

Теперь эта хеш-коллекция не является коллекцией объектов Собака！

Псевдонимы типов

Используйте псевдонимы типов, когда они позволяют удобно именовать или разъяснять цели, но не искажают типы, которые и так очевидны.

() => 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
}

Обратите внимание на то, что псевдонимы, это не новые типы - они эквивалентны синтаксической замене типа новым именем.

Неявные преобразования

Неявные преобразования являются мощной возможностью системы типов, но они должны использоваться там, где необходимы. Они усложняют правила преобразования трудоемкими — если по простому, то лексическим сравнением — чтобы понять, что на самом деле происходит. Обычно неявные преобразования используются в следующих ситуациях:

• Расширение или добавление коллекций в стиле Scala
• Адаптация или расширение объекта (шаблон “pimp my library”)
• Для повышения безопасности типов, предоставляя ограниченный набор данных
• Чтобы предоставить данные типа (typeclassing)
• Для Манифестов

Если действительно хотите использовать неявные преобразования, прежде всего спросите себя, есть ли способ достигнуть той же цели без их помощи.

Не используйте неявные преобразования, чтобы сделать автоматическое преобразование между похожими типами данных (например, преобразование списка в поток); это лучше сделать явно, потому что у типов есть различная семантика, и читатель должен остерегаться подобных реализаций.

Коллекции

Иерархия

Библиотека коллекций очень большая: в дополнение к сложной иерархии - корнем которой является Traversable[T] - существуют immutable и mutable варианты для большинства коллекций. Несмотря на сложность, на следующей диаграмме содержатся важные различия между immutable и mutable иерархиями

Iterable[T] - это любая коллекция, элементы которой могут быть проитерированы, она имеет метод iterator(а также метод foreach).Seq[T]- это коллекция, элементы которой отсортированы,Set[T]- является аналогом математического множества (неупорядоченная коллекция уникальных элементов), и Map[T] - который представляет собой неотсортированный ассоциативный массив.

Применение

• Предпочитительнее использовать immutable коллекции.* Они применимы в большинстве случаев, и делают программу проще и прозрачнее,а также потокобезопасной.

• Используйте mutable пространство имен явно.* Не импортируйте scala.collection.mutable._, а ссылку на set, лучше сделать так

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

так становится ясно, что используется mutable вариант

• Используйте стандартный конструктор для коллекций.* Всякий раз, когда вам нужна упорядоченная последовательность (и не обязательно связанный список), используйте конструктор Seq(), или ему подобный вариант:

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

Стиль

Функциональное программирование призывает к цепочечным преобразованиям immutable коллекций для получения желаемого результата. Это часто приводит к очень коротким решениям, но также может ввести в заблуждение читателя - часто трудно понять намерения автора, или отслеживать все промежуточные результаты, которые подразумеваются. Например, предположим, что мы хотим подсчитать голоса за разные языки программирования из определенного набора (язык, число голосов); показывая их, в порядке убывания числа голосов, мы могли бы написать:

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 скрывает операции упаковки/распаковки от нас, но они могут серьезно влиять на производительность или оказывать противоположное действие.

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 тысяч одновременных операций - и их обработка подразумевают сложность, которая является центральной темой в надежных программных системах.

Потоки являются средством выражения параллелизма: они дают вам независимые контексты выполнения с общей разделяемой памятью, которая управляется операционной системой. Тем не менее, создание потоков является затратной операцией в Java и этим ресурсом необходимо управлять, как правило, с использованием пулов. Это создает дополнительные сложности для программиста, а также обладает высокой степенью связности: трудно отделить логику приложения от используемых им основных ресурсов.

Эта сложность особенно заметна при создании сервисов, которые имеют высокую степень параллелизма: каждый приходящий результат запроса в множество всех запросов на каждый уровень системы. В таких системах, пулы потоков должны быть организованы таким образом, чтобы они быди сбалансированы в зависимости от количества запросов на каждом уровне: беспорядок в одном пуле потоков негативно влияет на другие.

Надежная система должна также не упускать из виду тайм-ауты и отказы, оба этих элемента требуют введения дополнительного «контроля» потоков, тем самым усложняя проблему еще больше. Заметим, что если бы потоки были более дешевыми, то эти проблемы стали бы меньше: необходимость в пулах, тайм-аутах потоков можно было бы отбросить, и никаких дополнительных ресурсов для управления не потребовалось бы.

Таким образом, управление ресурсами ставит под угрозу модульность.

Futures

Коллекции

С параллельными коллекциями связано множество мнений, тонкостей, догм, страха, неуверенности и сомнения. В большинстве практических ситуаций, они не являются проблемой: Всегда начинайте с самой простой, самой невзрачной, и стандартной коллекции, которая послужит поставленной цели. Не используйте параллельную коллекцию до того, как вы будете знать, что синхронизированный вариант коллекции не работает: JVM имеет современные механизмы, чтобы сделать синхронизацию дешевой операцией, так что их эффективность может вас удивить.

Если необходимо использовать immutable коллекцию, используйте - она совершенно прозрачна, поэтому рассуждать о них в контексте параллельных вычислений очень просто. Изменения в immutable коллекциях, как правило, выполняются путем обновления ссылки на текущее значение (в var ячейке или AtomicReference). Необходимо соблюдать осторожность, чтобы верно это применять: атомы должны быть повторно объявлены, и переменные должны быть объявлены на лету в порядке их объявления в других потоках.

Mutable параллельные коллекции имеют сложную семантику, и используют тонкости модели памяти в Java, поэтому убедитесь, что вы понимаете последствия - особенно при распространении обновлений - прежде чем начинать использовать их. Синхронные коллекции тоже неплохой вариант: операции, такие как getOrElseUpdate не могут быть правильно реализованы для параллельных коллекций, и создание сложных коллекций особенно подвержено ошибкам.

Управляющие структуры

Программы в функциональном стиле, как правило, требуют меньше традиционных управляющих структур, да и читать код лучше, когда он написан в декларативном стиле. Это обычно означает, разделение вашей логики на несколько небольших методов или функций, и склеивание их вместе с match выражениями. Функциональные программы также имеют тенденцию быть более ориентированными на выражения: ветви условных выражений для значений того же типа, 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
    }
  }
}

Возврат значений

Это не означает, что императивные структуры бесполезны. Во многих случаях они хорошо подходят для прекращения вычислений вместо условных переходов для всех возможных вариантов окончания вычислений: ведь в приведенном выше fixDown, return используется для досрочного прекращения, если мы в конце кучи.

Возврат значений может быть использован, чтобы сократить количество ветвлений и установить инварианты. Он помогает читателю за счет уменьшения вложенности и делает легче рассуждения о правильности последующего кода (доступ к элементу массива не может происходить за границей массива). Это особенно полезно в “guard” выражениях:

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

лучше использовать:

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

Обратите внимание, что использование returns тоже имеет свою цену: при использовании внутри замыкания,

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

  // process...
}

в байт-коде это реализовано в виде пары исключений catching/throwing, использование которых в реальном коде, влияет на производительность.

Циклы for и генераторы

for обеспечивает краткий и естественный способ для циклической обработки данных и их накопления. Это особенно полезно, когда обрабатывается много последовательностей. Синтаксис for противоречит основному механизму выделения и управления замыканиями. Это может привести к непредвиденным расходам и двусмысленности, например

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

. LP может привести к ошибке выполнения, если произойдет задержка при вычислении container, что делает return не локальным!

По этим причинам, обычно предпочтительнее, вызвать foreach, flatMap, map и filter напрямую - но стоит использовать for для того, чтобы прояснить вычисления.

require и assert

require и assert, оба оператора описаны в документации. Оба полезны для ситуаций, в которых система типов не может определить нужный вариант типа. assert, используется для инвариантов, которые предполагаются в коде (или внутреннем или внешнем), например

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

В то время как require используется для представления API контрактов:

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

Функциональное программирование

Программирование ориентированное на значение дает много преимуществ, особенно когда используется в сочетании с конструкциями функционального программирования. Этот стиль делает ставку на преобразовании значений вместо изменения состояния, возвращая код, который более прозрачен, обеспечивая больше инвариантов, а значит и легче в понимании. Case классы, сопоставление с образцом, несвязность, вывод типов, и легковесное создание замыканий и методов образуют синтаксис, который является предметом обсуждений.

Case классы как алгебраический тип данных

Case классы представляют собой АТД(алгебраический тип данных): они полезны для моделирования большого числа структур данных и обеспечивают более короткий код с мощными инвариантами, особенно при использовании сопоставления с образцом. Сопоставление с образцом реализует исчерпывающий анализ, обеспечивая равномерные статические гарантии.

При использовании следующего примера с использованием АТД и Case классов:

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. Объявление типа 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
}

В то время как рекурсивные структуры, такие как деревья представляют собой классические реализации АТД, областей их полезного применения намного больше. Несвязные объединения, в частности, легко моделируется с помощью абстрактных типов данных; они часто встречаются в различных состояниях машины.

Опция

Тип Option - это контейнер, который либо пуст (None), либо полон (Some(value)). Он обеспечивает безопасную альтернативу использованию null, и должен быть использован вместо null всякий раз, когда это возможно. Эти типы являются коллекциями (содержащими не более одного элемента) и они используют методы коллекций - чаще используйте их!

Пишите

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

вместо

var username: String = null
...
username = "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 коде: оно осуществляет условное выполнение, разбор конструкций, и все это в одной конструкции. При его использовании также повышается четкость и безопасность.

Используйте сопоставление с образцом для реализации переключения типов:

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

Сопоставление с образцом лучше всего работает в сочетании с разбором конструкций (например, работе с 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 }

Разрушение связей (Destructuring bindings)

Разрушение связей тесно связано с сопоставлением с образцом; используется тот же механизм, но применяется, когда есть только один вариант (чтобы не сгенерировать исключение). Разрушение связей особенно полезно для кортежей и Case классов.

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

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

Ленивые вычисления

Поля в Scala вычисляются при необходимости, если val имеет префикс lazy. Поэтому поля и методы в Scala подобны (поля как бы private[this]):

lazy val field = computation()

это сокращение для

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

где, результаты вычисляются и запоминаются. Используйте ленивые поля для этих случаев, но избегайте использования ленивых вычислений, когда ленивые вычисления требуются по смыслу. В этих случаях лучше производить вычисления явно, поскольку можно точно произвести оценку, и побочные эффекты могут контролироваться более точно.

Ленивые поля являются потокобезопасными.

Передача по имени

Параметры методов могут быть переданы по имени, то есть параметр принимает не значение, а вычисление, которое может повторяться. Это функция должна применяться с осторожностью; вызывающая функция может ожидать передачу по значению, но ответ ее удивит. Способ применения этой особенности - это построение обычных синтаксических DSL - например, могут быть сделаны новые конструкции управления, чтобы выглядеть так же, как и родные особенности языка.

Используйте передачу по имени управляющих конструкций, когда для вызывающей функции очевидно, что передается в этот “блок”, вместо результата каких-то неожиданных вычислений. Записывайте передачу по имени в крайней позиции последнего списка аргументов. При использовании передачи по имени, убедитесь, что метод назван очевидным образом для вызывающей функуции, которая передает аргумент.

Если вы хотите, чтобы значения вычислялись несколько раз, и, особенно, когда вычисление имеет побочные эффекты, используйте явные функции:

class SSLConnector(mkEngine: () => SSLEngine)

ваше намерение остается очевидным и для вызывающей функции это не будет сюрпризом

flatMap

flatMap - сочетает в себе map и flatten - заслуживающие особого внимания, потому что они обладают небольшой мощью, но очень полезны. Подобно map, она доступна в нетрадиционных коллекциях, таких как Future и Option. Поведение функции раскрывается при описании; например Container[]

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

flatMap вызывает функцию f для элемента(ов) из коллекции создавая новую коллекцию, из всех тех, которые дают нужный результат. Например, чтобы получить все перестановки двух символьных строк, у которых нет общих символов, напишем дважды:

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

что эквивалентено, но более кратко и понятно (что само по себе —грубый— синтаксический сахар для написанного выше), этому коду:

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

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 также имеет примеси (Mixins), позволяющие более четкое построение модулей, которые можно гибко собрать на этапе компиляции со всеми преимуществами статической проверки типов.

Внедрение зависимостей

На своем опыте мы обнаружили, что Scala на самом деле удаляет большую часть синтаксических издержек “классического” (в конструкторе) внедрения зависимостей, и мы можем это использовать это: более ясное описание, зависимости все еще закодированы в типе, а конструкция класса так синтаксически проста, что это становится незаметно. Это скучно и просто, и это работает. Используйте внедрение зависимостей для модульного построения программы, и в частности предпочитайте композицию наследованию - это приведет к более модульным и легко тестируемым программам. Если возникает ситуация, когда требуется наследование, то спросите себя: как бы вы спроектировали программу, если бы язык не имел такой возможности, как наследование? Ответ может быть не так прост.

Для внедрения зависимостей обычно используются трейты(traits),

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

Трейты(Traits)

Внедрение зависимостей вовсе не исключает возможности использования общих интерфейсов, или релизации общего кода в трейтах. Совсем наоборот - использование трейтов настоятельно рекомендуется именно по этой причине: несколько интерфейсов (трейтов) могут быть реализованы в конкретном классе, а общий код может быть использован во всех таких классах.

Старайтесь писать трейты короткими и простыми: но не стоит разделять функциональности между трейтами, думайте о них, как о небольших кусочках, которые связаны друг с другом. Например, представьте, что у вас есть то, что может сделать 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])
}

или объедините их вместе, чтобы получить то, что было в IOer: new Reader with Writer… минимализм трейта приводит к простоте и более "чистой" модульности.

Видимость

Скала имеет очень выразительные модификаторы видимости. Важно использовать их, так как они определяют то, что представляет собой публичный API. Публичные API должны быть ограничены так, чтобы пользователи случайно не полагались на реализацию деталей и предел возможностей автора менять их: они имеют решающее значение при постороение хорошей модульности. Как правило, гораздо проще расширять публичные API, чем их сокращать. Плохие аннотации также могут подорвать обратную бинарную совместимость вашего кода.

private[this]

Член класса помеченный как private,

private val x: Int = ...

видим для всех экземпляров этого класса (но не и подклассов). В большинстве случаев вам нужен private[this].

private[this] val: Int = ..

который ограничивает видимость для конкретного экземпляра.Компилятор Scala также может переводить private[this] в простое поле для доступа (поскольку доступ ограничен для статически определенного класса), которое иногда может помочь при оптимизации производительности.

Класс синглтон (Singleton)

Общепринятая в 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 - все это побочный продукт функционального стиля. Сборщик мусора обычно делает это без проблем так как короткоживущий мусор эффективно собирается в большинстве случаев.

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

Futures

Offer/Broker

Благодарности

Уроки в этом документе, принадлежат Scala сообществу в Twitter, - и я надеюсь, Я был верным летописцем.

Blake Matheny, Nick Kallen, Steve Gury, и Raghavendra Prabhu предоставили множество полезных советов и превосходных предложений