effectivescala-ru.mo

<a href="http://github.com/twitter/effectivescala"><img style="position: absolute; top: 0; left: 0; border: 0;" src="https://s3.amazonaws.com/github/ribbons/forkme_left_green_007200.png" alt="Fork me on GitHub"></a>

<h1 class="header">Effective Scala</h1>
<address>Marius Eriksen, Twitter Inc.<br />marius@twitter.com (<a href="http://twitter.com/marius">@marius</a>)<br /><br />[translated by Eugene Sysmanov(<a href="https://github.com/appigram">@appigram</a>)]</address>

<h2>Table of Contents</h2>

.TOC


<h2>Перевод на другие языки</h2>
<a href="index.html">English</a>
<a href="index-ja.html">日本語</a>

## Введение

[Scala][Scala] является одним из основных языков программирования, который испоьзуется в Twitter. Большая часть нашей инфрастуктуры написана на Scala и [у нас есть несколько крупных библиотек](http://github.com/twitter/), которые нами поддерживаются.

Scala не только очень эффективный, но и большой язык. Полученный нами опыт, научил нас быть очень осторожным при его использовании в своих приложениях в боевых условиях. Какие есть подводные камни? Какие особенности стоит использвать, а от каких отказаться? Когда мы можем использовать «чисто функциональный стиль», а когда его следует избегать? Другими словами: что мы ежедневно используем, чтобы быть более эффективными используя этот язык? Это руководство пытается передать наш опыт в коротких заметках, представляя их как набор *лучших практик*. Мы используем Scala для создания высококачественных сервисов, которые представляют собой распределенные системы - наше мнение возможно будет предвзято - но большинство советов здесь должны работать без проблем и 
при переносе на другие системы. Все эти советы не явяются истиной в последней инстанции, и небольшое отклонение должно быть вполне приемлимым.


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

Немного, о *Scala-программе*. Вы не пишете код ни на Java, ни на Haskell, ни на Python; написание Scala-программы отличается от написания на любом из этих языков. Для того чтобы использовать язык эффективно, вы должны описать свои проблемы, в терминах этого языка. Вас никто не принуждает использовать программу, написанную на Java, в Scala, в большинстве случаев она будет уступать оригиналу.

Данный документ не введение в язык Scala, мы предполагаем, что читатель
знаком с языком. Вот некоторые ресурсы для обучения языку Scala:

* [Scala School](http://twitter.github.com/scala_school/)
* [Learning Scala](http://www.scala-lang.org/node/1305)
* [Learning Scala in Small Bites](http://matt.might.net/articles/learning-scala-in-small-bites/)

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

И получайте удовольствие.

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

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

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

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

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

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

### Именование

<dl class="rules">
<dt>Используйте короткие имена для небольших областей видимости</dt>
<dd>Применяйте <code>i</code>,<code>j</code> и <code>k</code> и тому подобные переменные в циклах </dd>
<dt>Используйте длинные имена для больших областей видимости</dt>
<dd>Внешние API должны иметь длинные и понятные имена, которые придают смысл.
<code>Future.collect</code> вместо <code>Future.all</code>.
</dd>
<dt>Используйте стандартные сокращения, и откажитесь от эзотерических</dt>
<dd>
Всем известны <code>ok</code>, <code>err</code> или <code>defn</code>,а вот <code>sfri</code> используется не так часто.
</dd>
<dt>Не используйте одни и теже имена для различных целей</dt>
<dd>Применяйте <code>val</code></dd>
<dt>Избегайте использования <code>`</code> для перегрузки зарезервированных имен.</dt>
<dd>Используйте <code>typ</code> вместо <code>`type</code>`</dd>
<dt>Используйте в имени active для операций с побочными эффектами</dt>
<dd><code>user.activate()</code> вместо <code>user.setActive()</code></dd>
<dt>Используйте описательные имен для методов, которые возвращают значения</dt>
<dd><code>src.isDefined</code> вместо <code>src.defined</code></dd>
<dt>Не используйте у геттеров(getter) префикс <code>get</code></dt>
<dd>В соответствии с предыдущим правилом: лучше применять <code>site.count</code> вместо <code>site.getCount</code></dd>
<dt>Не используйте повторно имена, которые уже есть в пакете или в названии объекта</dt>
<dd>Предпочтительно:
<pre><code> object User {
   def get(id: Int): Option[User]
}</code></pre>вместо
<pre><code>object User {
   def getUser(id: Int): Option[User]
}</code></pre>Они являются избыточными, так как при использовании: <code>User.getUser</code> дает не больше информации, чем <code>User.get</code>.
</dd>
</dl>

### Импорт

<dl class="rules">
<dt>Располагайте строки импорта в алфавитном порядке</dt>
<dd>Так их проще определить визуально, и так проще для автоматизации.</dd>
<dt>Используйте фигурные скобки при импортировании нескольких имен из пакета</dt>
<dd><code>import com.twitter.concurrent.{Broker, Offer}</code></dd>
<dt>Используйте символ подчеркивания, когда импортируйте более 6 имен</dt>
<dd>например: <code>import com.twitter.concurrent._</code>
<br />Не применяйте этот знак без оглядки, некоторые пакеты экспортируют слишком много имен</dd>
<dt>Когда используете коллекции, уточняйте имена при импортировании <code>scala.collection.immutable</code> и/или <code>scala.collection.mutable</code></dt>
<dd>Изменяемые и неизменяемые коллекции имеют двойные имена. Уточнение имен сделает очевидным для читателя какой вариант используется (например "<code>immutable.Map</code>")</dd>
<dt>Не используйте относительный импорт из других пакетов</dt>
<dd>Избегайте <pre><code>import com.twitter
import concurrent</code></pre> в пользу более одназначного <pre><code>import com.twitter.concurrent</code></pre></dd>
<dt>Располагайте строки импорта вверху файла</dt>
<dd>Читатель может обратится ко всем строкам импорта в одном месте</dd>
</dl>

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

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

	def square(х: Int) = х*х

.LP, вместо

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

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

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

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

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

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

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

.LP ясно, что элементы списка в настоящее время отображаются более ясно &mdash; дополнительно уточнять ничего не нужно.

### Комментарии

Используйте [ScalaDoc](https://wiki.scala-lang.org/display/SW/Scaladoc), чтобы предоставлять документацию по API. Используйте следующий стиль:

	/**
	 * ServiceBuilder builds services 
	 * ...
	 */
	 
.LP <em>вместо</em>стандартного стиля ScalaDoc:

	/** ServiceBuilder builds services
	 * ...
	 */

Не прибегайте к ASCII искусству или другим визуальным украшениям. Документируйте API, но не добавляйте ненужных комментариев. Если вы добавляете комментарии, чтобы объяснить поведение вашего кода, сначала спросите себя, может ли код быть переписан так, чтобы стало очевидным, что он делает. Лучше предпочесть "Очевидно, это работает" вместо "Это работает, очевидно" (цитата Энтони Хоара).

(прим. переводчика: "Есть два метода создания программного обеспечения. Один из них — сделать программу настолько простой, что, очевидно, в ней нет недостатков. И другой, сделать приложение настолько сложным, что в нем невидно явных недостатков." - [Энтони Хоар](http://ru.wikipedia.org/wiki/Хоар,_Чарльз_Энтони_Ричард) выдержка из лекции, [Премия Тьюринга](http://amturing.acm.org/award_winners/hoare_4622167.cfm))

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

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

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

Мощная система типов в 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
	}

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

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

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

	trait Mammal
	trait Dog extends Mammal
	trait Cat extends Mammal

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

	val dogs: HashSet[Dog]

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

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

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

(прим. переводчика: Подробнее о [ковариантности и контрвариантности](http://chabster.blogspot.com/2008/01/type-system-covariance-and.html))

<!--
  *	when to use abstract type members?
  *	show contravariance trick?
-->

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

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

	() => Int

.LP данная запись более понятна чем

	type IntMaker = () => Int
	IntMaker

.LP так как это короче и используется общий тип, однако

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

.LP более полезен, так как передает цель и улучшает краткость.

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

	trait SocketFactory extends (SocketAddress => Socket)
	
.LP <code>SocketFactory</code> <em>это</em> функция которая создает <code>Socket</code>. Использование псевдонима

	type SocketFactory = SocketAddress => Socket

.LP более правильно. Теперь мы можем обеспечить функциональные идентификаторы для значений типа<code>SocketFactory</code>, а также использовать композицию функций:

	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)
* Для `Манифестов`

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

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

## Коллекции

У Scala есть универсальная, богатая, мощная, и прекрасно составленная библиотека коллекций; коллекции - высокоуровневые реализации и они представляют собой большой набор различный операций. Множество действий с коллекциями и преобразования над ними могут быть выражены кратко и четко, но небрежное применение функций может привести к противоположному результату. Каждый Scala-программист должен прочитать [Сollections design document](http://www.scala-lang.org/docu/files/collections-api/collections.html);
он даст большее понимание при работе с библиотекой коллекций в Scala.

Всегда используйте самую простую коллекцию, которая соответствует вашим потребностям потребностям.

### Иерархия

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

<img src="coll.png" style="margin-left: 3em;" />
.cmd
pic2graph -format png >coll.png <<EOF 
boxwid=1.0

.ft I
.ps +9

Iterable: [
	Box: box wid 1.5*boxwid
	"\s+2Iterable[T]\s-2" at Box
]

Seq: box "Seq[T]" with .n at Iterable.s + (-1.5, -0.5)
Set: box "Set[T]" with .n at Iterable.s + (0, -0.5)
Map: box "Map[T]" with .n at Iterable.s + (1.5, -0.5)

arrow from Iterable.s to Seq.ne
arrow from Iterable.s to Set.n
arrow from Iterable.s to Map.nw
EOF
.endcmd

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

### Применение

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

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

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

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

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

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

.LP Этот стиль отделяет семантику коллекции от ее реализации, позволяя библиотеке коллекций использовать наиболее подходящий тип: если вам нужен <code>Map</code>, не обязательно использовать <a href="http://ru.wikipedia.org/wiki/Красно-чёрное_дерево">Красно-черное дерево(Red-Black Tree)</a>. Кроме того, стандартные конструкторы будут часто использовать специализированные представления: например, <code>Map()</code> будет использовать объект с 3 полями для объектов с 3 ключами(<a href="http://www.scala-lang.org/api/current/scala/collection/immutable/Map$$Map3.html"><code>Map3</code></a>).

В заключение, к сказанному выше: в ваших собственных методах и конструкторах *старайтесь использовать самую универсальную коллекцию*. Обычно это сводится к одной из приведенных: `Iterable`, `Seq`, `Set`, или `Map`. Если ваш метод нуждается в последовательности, используйте `Seq[T]`, а не `List[T]`.

<!--
something about buffers for construction?
anything about streams?
-->

### Стиль

Функциональное программирование призывает к цепочечным преобразованиям
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

.LP это кратко и правильно, но почти любому читателю нужно время, чтобы восстановить в голове первоначальные намерения автора. Стратегия, которая призвана уточнить решение <em>использование промежуточных результатов и параметров</em>:

	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

.LP код является почти столь же кратким, но гораздо более четко описывает происходящие превращения (благодаря именованным промежуточным значениям), и структуры данных с которыми работает программа (именованные параметры). Если вы беспокоитесь о засорении пространства имен, применяя этот стиль, используйте группировку выражений с помощью <code>{}</code>:

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


### Производительность

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

Прежде, чем сфокусироваться на низкоуровневых деталях, удостоверьтесь, что используете коллекцию, подходящую для данного случая. Удостоверьтесь, что ваша структура данных не имеет неожиданной асимптотической сложности. Возникающие при работе сложности для разных Scala коллекций описаны [здесь](http://www.scala-lang.org/docu/files/collections-api/collections_40.html).

Первое правило оптимизации производительности состоит в том, чтобы понять *почему* ваше приложение медленно работает. Не стоит действовать без оглядки; профилируйте^ [Yourkit](http://yourkit.com) - неплохой профилировщик] приложение перед тем как действовать дальше. Фокусируйтесь сначала на интенсивно используемых циклах и больших структурах данных. Чрезмерные усилия на оптимизацию обычно тратятся впустую. Помните принцип Кнута: "Преждевременная оптимизация - корень все зол."

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

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

Используйте futures(актор с возможностью блокировки создающего его потока, если создающий поток запросил результат вычисления - прим. переводчика) для управления параллелизмом. Они позволяют отделить параллельные операции от управления ресурсами: например, [Finagle][Finagle] объединяет параллельные операции в несколько потоков эффективным
образом. Scala имеет легковесный синтаксис замыканий, поэтому futures вводят немного синтаксического сахара; и они становятся все более популярны среди программистов.

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

*Изменяйте futures вместо создания собственных.* Futures позволяют поймать ошибку, определить сигнал отказа, и позволяет программисту не думать о релизации модели памяти в Java. Осторожный программист может написать следующее решение для RPC последовательности из 10 элементов, а затем напечатать результаты:

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

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

*Используйте Futures комбинаторы*. `Future.select`, `Future.join`, и `Future.collect` реализуют общие шаблоны при работе над несколькими Futures, которые должны быть объединены.

### Коллекции

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

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

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

<!--

use the stupid collections first, get fancy only when justified.

serialized? synchronized?

blah blah.

Async*?

-->


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

Программы в функциональном стиле, как правило, требуют меньше традиционных управляющих структур, да и читать код лучше, когда он написан в декларативном стиле. Это обычно означает, разделение вашей логики на несколько небольших методов или функций, и склеивание их вместе с `match` выражениями. Функциональные программы также имеют тенденцию быть более
ориентированными на выражения: ветви условных выражений для значений того же типа, `for (..) yield` вычисление дополнений, и рекурсия являются обычным делом.

### Рекурсия

*Формулировка проблемы в терминах рекурсии обычно упрощает ее*, и если применяется оптимизация хвостовой рекурсии (которая может быть проверена с помощью аннотации `@tailrec`), компилятор преобразует ​​код в обычный цикл.

Рассмотрим довольно стандартную императивную реализацию кучи <span class = "algo">fix-down</span>:

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

Каждый раз, при входе в цикл, мы работаем с состоянием предыдущей итерации. Значением каждой переменной является результат вычисления функции определенной ветви выполнения, и значение возвращается в середине цикла, если был найден верный результат вычисления (внимательный читатель найдет похожие
аргументы в Дейкстры ["О вреде оператора Go To"](http://www.vspu.ac.ru/~chul/dijkstra/goto/goto.htm)).

Рассмотрим реализацию (хвостовой) рекурсии^[Из [Finagle's heap balancer](https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/loadbalancer/Heap.scala#L41)]:

	@tailrec
	final def fixDown(heap: Array[T], i: Int, j: Int) {
	  if (j < i*2) return
	
	  val m = if (j == i*2 || heap(2*i) < heap(2*i+1)) 2*i else 2*i + 1
	  if (heap(m) < heap(i)) {
	    swap(heap, i, m)
	    fixDown(heap, m, j)
	  }
	}

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

<!--
elaborate..
-->


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

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

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

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

.LP но использование выражения <code>match</code> подходит лучше:

	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...
	}
	
.LP в байт-коде это реализовано в виде пары исключений catching/throwing, использование которых в реальном коде, влияет на производительность.

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

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

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

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

По этим причинам, обычно предпочтительнее, вызвать `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]

.LP  тип <code>Tree[T]</code>имеет два конструктора: <code>Node</code> и <code>Leaf</code>. Объявление типа <code>sealed</code> позволяет компилятору сделать исчерпывающий анализ, поскольку конструкторы не могут быть добавлены в другом исходном файле.

Вместе с использованием сопоставления с образцом, мы получаем краткие и "очевидно правильные" результаты моделирования в коде:

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

.LP вместо

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

.LP первый вариант безопаснее: тип <code>Option</code> статически проверяет что <code>Username</code> должен быть заранее проверен на пустоту.

Применение в условных конструкциях `Option` значений должно быть сделано с помощью `foreach`, вместо

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

.LP пишите

	opt foreach { value =>
	  operate(value)}

Стиль может показаться странным, но обеспечивает большую безопасность (мы не вызываем исключительно `get`) и краткость. Если есть два варианта выполнения, то при использовании сопоставления с образцом получим:

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

.LP но если все варианты ложные, то для значений по умолчанию, используйте <code>getOrElse</code>

	operate(opt getOrElse defaultValue)

Не злоупотребляйте `Option`: если имеется значение по 
умолчанию - [*Null Object*](http://en.wikipedia.org/wiki/Null_Object_pattern) - используйте его.

`Option` также предоставляет удобный конструктор для упаковки nullable значения:

	Option(getClass.getResourceAsStream("foo"))

.LP выражение является <code>Option[InputStream]</code> который может принимать значение <code>None</code>, в этом случае <code>getResourceAsStream</code> должен возвратить <code>null</code>.

### Сопоставление с образцом

Сопоставление с образцом (`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
	  }

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

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


Используйте [custom extractors](http://www.scala-lang.org/node/112), но только с дополнительным конструктором (`apply`), в противном случае их использования может быть неуместным.

Не используйте сопоставление с образцом для вычисления условий, когда имеет смысл использовать стандартные значения. Библиотеки коллекций  обычно предоставляют методы, которые возвращают `Option`; избегайте такого кода

	val x = list match {
	  case head :: _ => head
	  case Nil => default
	}

.LP потому что

	val x = list.headOption getOrElse default

.LP так короче и больше соответствует цели

### Частичные функции

Scala предоставляет синтаксический сахар для определения `PartialFunction`:

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

.LP они могут использоваться вместе с <code>orElse</code>

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

.LP или в ситуациях, которые могли бы способствовать возврату <code>Option</code>

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

.LP все это может быть лучше выражено с помощью <code>PartialFunction</code>

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

.LP так как это более компактно:

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

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

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

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

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

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

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

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

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

	class SSLConnector(mkEngine: () => SSLEngine)

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

### `flatMap`

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

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

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

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

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

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

.LP данный пример также кратко можно написать с использованием <code>for</code>

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

Использование `flatMap` в `Future` обсуждается в  
<a href="#Twitter's%20standard%20libraries-Futures">разделе futures</a>.

## Объектно-ориентированное программирование

Большая часть возможностей Scala обеспечивается благодаря объектной системе. Scala является *чистым* языком в этом смысле, потому что *все элементы* являются объектами, нет различия между примитивными типами и составными. Scala также имеет примеси (Mixins), позволяющие более четкое построение модулей, которые можно гибко собрать на этапе компиляции со всеми преимуществами статической проверки типов.

Основная идея системы примесей в том, чтобы избежать необходимости в традиционном построение зависимостей. Кульминацией этого "компонентного стиля" программирования  является [the cake pattern](http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di/).

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

На своем опыте мы обнаружили, что 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]
	}
	
.LP разделите код на два поведения:

	trait Reader {
	  def read(n: Int): Array[Byte]
	}
	trait Writer {
	  def write(bytes: Array[Byte])
	}
	
.LP или объедините их вместе, чтобы получить то, что было в <code>IOer</code>: <code> new Reader with Writer</code>&hellip; минимализм трейта приводит к простоте и более "чистой" модульности.

### Видимость

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

#### `private[this]`

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

	private val x: Int = ...
	
.LP видим для всех <em>экземпляров</em> этого класса (но не и подклассов). В большинстве случаев вам нужен <code>private[this]</code>.

	private[this] val: Int = ..

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

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

Общепринятая в Scala практика по созданию класса синглтона, например

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

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

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

.LP где вызывающие <code>foo()</code> участки кода будут ограничены с помощью (<code>Foo with Bar</code>) для возвращаемого экземпляра.

### Структурная типизация

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

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

## Сборка мусора

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

Прежде чем пытаться бороться с проблемами производительности сборщика мусора, посмотрите [это](http://www.infoq.com/presentations/JVM-Performance-Tuning-twitter) Выступление Аттилы, который иллюстрирует некоторый наш опыт по настройке сборщика мусора.

В Scala собственно вашим единственным инструментом облегчения проблем со сборщиком мусора является создание меньшего количества мусора, но не стоит дествовать без предварительных данных! Пока вы не сделали того, что явно ухудшит ситуацию, используйте различные инструменты профилирования Java - Наши собственные инструменты включают [heapster](https://github.com/mariusaeriksen/heapster) и [gcprof](https://github.com/twitter/jvmgcprof).

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

Наиболее важными стандартными библиотеками в Twitter являются
[Util](http://github.com/twitter/util) и [Finagle](https://github.com/twitter/finagle). Util должна 
рассматриваться как расширение для стандартной библиотеки Scala и Java, предоставляя недостающую функциональность и более соответствует конкретной реализации. Finagle - это наша RPC система, ядро ​​распределенных системных компонентов.

### Futures

Futures <a href="#Параллелизм-Futures">обсуждались</a> 
коротко в <a href="#Параллелизм">разделе о параллельных вычислениях</a>. Они являются центральным механизмом координации асинхронных процессов и широко распространены в нашем кода и в ядре Finagle. Futures позволяют объединять одновременные события, а также упрощают рассуждения о высокопараллельных операциях. Их можно эффективно реализовать на JVM.

Futures в Twitter являются *асинхронными*, так что блокирование операций - в основном любой операции, может быть приостановлено при выполнении своим потоком; сетевой ввод-вывод и дисковый ввод-вывод, например - должны быть обработаны системой, что обеспечивают сами futures для результатов указанных операций. Finagle предоставляет такую систему для сетевого ввода-вывода.

Futures являются простыми и понятными: они *ждут* результата вычислений, которые еще не завершились. Они представляют собой просто контейнер - заполнитель. Вычисление может и не закончится, и это должно быть закодировано: Future может находится ровно в одном из 3-х состояний: *в ожидании*,
*провалено* или *завершено*.

<div class="explainer">
<h3>Aside: <em>Композиция</em></h3>
<p>Давайте вернемся к тому, что мы подразумеваем под композицией: сочетание простых компонентов в более сложных. Самый распространенный пример, это функция композиции: Даны функции <em>f</em> и <em>g</em>, функция композиции <em>(g&#8728;f)(x) = g(f(x))</em> &mdash; сначала результат получаем применения <em>x</em> в <em>f</em>, и потом результат этого выражения применяется в <em>g</em> &mdash; может быть записано на Scala:</p>

<pre><code>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</code></pre>

.LP функция <em>h</em> будет композитной. Это <em>новая</em> функция, которая объединяет <em>f</em> и <em>g</em>.
</div>

Futures являются своего рода коллекцией - это контейнер из 
0 или 1 элементов - и вы увидите, что они имеют стандартные
методы коллекций (например, `map`, `filter`, и `foreach`). С Future значение откладывается(deferred), результат применения любого из этих методов также откладывается, в

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

.LP функция <code>{ i => i.toString }</code> не вызывается, пока целочисленное значение не становится доступно, и преобразвание коллекции <code>resultStr</code> также откладывается до этого момента.

Списки могут быть свернуты;

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

.LP и тоже самое можно сделать для futures:

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

.LP с futures происходит задержка, реализация <code>flatten</code> &mdash; должна немедленно &mdash; вернуть future, который ждет завершения внешнего future (<code><b>Future[</b>Future[Int]<b>]</b></code>) и после этого выполняется внутренний (<code>Future[<b>Future[Int]</b>]</code>). Если внешний future завершается с ошибкой, свернутый future должен также завершиться с ошибкой.

Futures (подобны Спискам) также имеют `flatMap`; `Future[A]` объявление:

	flatMap[B](f: A => Future[B]): Future[B]
	
.LP который похож на комбинацию <code>map</code> и <code>flatten</code>, и можем реализовать это следующим способом:

	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 который является результатом двух последовательных futures, второй future вычисляется на основе 
результатов первого. Представьте себе, что мы должны были бы сделать два RPC для аутентификации пользователя (ID), то мы могли бы определить составную операцию следующим образом:

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

.LP Дополнительным преимуществом этого типа композиции является то, что есть встроенная обработка ошибок: future не возвратиться из <code>isAuthed(..)</code> если в одной из функций <code>getUser(..)</code> или <code>authenticate(..)</code> не пишется дополнительного кода для обработки ошибок.

#### Стиль

Future методы обратного вызова (callback) (`respond`, `onSuccess`, `onFailure`, `ensure`) вернут новый future, который *сцеплен* со своим родителем. Этот future гарантировано будет завершен только после завершения своего родителя, что позволяет писать так:

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

.LP где <code>freeResource()</code> гарантированно будет выполнен после <code>computeSomething</code>, позволяя эмуляцию шаблона <code>try .. finally</code>.

Используйте `onSuccess` вместо `foreach` -- он симметричен для `onFailure` это лучшее имя для подобного случая, и позволяет цепочечные вызовы.

Всегда старайтесь избегать `Promise` экземпляров напрямую: почти каждая задача может быть решена с помощью использования предопределенных комбинаций. Эти комбинации обеспечивают распространение ошибки и отказа, и в целом поощряют *стиль программирования потоков данных*, который обычно <href = "#Параллелизм-Futures">устраняет необходимость синхронизации и управления объявлениями</a>.

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

	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` определяют множество полезных методов: Use `Future.value()` и `Future.exception()` для создания заранее определенных futures. `Future.collect()`, `Future.join()` и `Future.select()` предоставляют комбинации, которые обращают многие futures в один (например, объединяются как часть операции сбора-разбора).

#### Отказ

Futures реализуют слабую форму отказа. Вызов `Future#cancel`
непосредственно не прекращает вычисления, но вместо этого устанавливает триггер *сигнал*, который может быть запрошен процессом, который в конечном счете удовлетворит требованиям future. Отказ распространяется в противоположном
направлении, чем значения: сигнал "отказ", установленный принимающим объектом распространяется до объекта, установившего этот сигнал. Объект, установивший сигнал, использует `onCancellation` и `Promise` слушать этот сигнал и действовать соответственно.

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

#### Locals

Утилита [`Local`](https://github.com/twitter/util/blob/master/util-core/src/main/scala/com/twitter/util/Local.scala#L40) предоставляет ссылочную ячейку, которая является локальной для конкретного future дерева диспетчеризации. Установка значения local делает это значение доступны для любого вычисления отложенного в том же потоке. Они, аналогичны locals потоков, за исключением того, что они не используются в потоках Java, а в дереве "future потоков". Например, в

	trait User {
	  def name: String
	  def incrCost(points: Int)
	}
	val user = new Local[User]

	...

	user() = currentUser
	rpc() ensure {
	  user().incrCost(10)
	}

.LP <code>user()</code> в блоке <code>ensure</code> будет ссылаться на значение <code>user</code>, локальное во время добавления функции обратного вызова.

Как и в потоковых locals, `Local` могут быть очень удобны, но их следует почти всегда избегать: убедитесь, что проблема не может быть решена путем передачи данных везде явно, даже если это несколько обременительно.

Locals эффективно используются в базовых библиотеках для *очень* общих задач - работа с потоками через RPC, передача мониторов, создание «трассировки стека» для будущих обратных вызовов - там, где любое другое решение было бы слишком обременительными для пользователей. Locals почти не подходят в любой другой ситуации.

### Offer/Broker

Работа параллельных систем сильно осложняется необходимостью координации
доступ к общим данным и ресурсам.[Акторы](http://www.scala-lang.org/api/current/scala/actors/Actor.html) предоставляют одну из стратегий упрощения работы: каждый актор это последовательный процесс, который сохраняет свое собственное состояние и ресурсы, а данные передаются путем передачи сообщений другим акторам. Обмен данными требует взаимодействия между акторами.

Offer/Broker состоит из трех важных компонентов. Во-первых, 
каналы связи (Broker) являются первым элементом - то есть, вы отправляете сообщения через Broker, а не актору напрямую. Во-вторых, Offer/Broker является синхронным механизмом: общение синхронизировано. Это значит, мы можем использовать Broker в качестве механизма координации: когда процесс `a` отправляет сообщение процессу `b`, оба процесса и `a` и `b` располагают состоянием системы. И наконец, связь может осуществляться *выборочно*: процесс может предложить несколько различных способов коммуникаций, а в итоге получит ровно один
из них.

Для того, чтобы поддерживать выборочные связи (а также другие соединения) в общем случае, мы должны отделить описание связи от процесса общения. Это то, что делает `Offer` - это постоянная величина, которая описывает связи, для выполнения коммуникации (действующей на Offer), мы синхронизируем процесс через метод `sync()`

	trait Offer[T] {
	  def sync(): Future[T]
	}

.LP который возвращает <code>Future[T]</code>, что дает возможность обменяться значениями, когда возникла связь.

`Broker` координирует обмен значениями через Offers - это канал связи

	trait Broker[T] {
	  def send(msg: T): Offer[Unit]
	  val recv: Offer[T]
	}

.LP так что при создании двух Offers

	val b: Broker[Int]
	val sendOf = b.send(1)
	val recvOf = b.recv

.LP и <code>sendOf</code> и <code>recvOf</code> оба синхронизированы

	// In process 1:
	sendOf.sync()

	// In process 2:
	recvOf.sync()

.LP обе Offers обменяются значением <code>1</code>.

Выборочная связь осуществляется путем объединения нескольких Offers с помощью `Offer.choose`

	def choose[T](ofs: Offer[T]*): Offer[T]

.LP что дает новые Offers, которые, при синхронизации, получают только один из <code>ofs</code> &mdash; первая из них станет доступной для дальнейших действий. Когда их становится несколько, доступных одновременно, один из них выбирается случайным образом.

Объект `Offer` имеет ряд одноразовых Offers, которые используются для объединения Offer с Broker.

	Offer.timeout(duration): Offer[Unit]

.LP это Offer, который активируется после передачи данного периода времени (duration). <code>Offer.never</code> никогда не получит данного значения, и <code>Offer.const(value)</code> сразу получает заданное значение. Они полезны при объединении, когда используется выборочная свзяь. Например, чтобы использовать задержку по времени операции отправки:

	Offer.choose(
	  Offer.timeout(10.seconds),
	  broker.send("my value")
	).sync()

Выглядит заманчиво, если сравнивать Offer/Broker с [SynchronousQueue](http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/SynchronousQueue.html),
но они отличаются небольшими, но важными деталями. Offers могут быть составлены таким образом, что таких очередей просто не существует. Например, рассмотрим набор очередей, представленых как Broker:

	val q0 = new Broker[Int]
	val q1 = new Broker[Int]
	val q2 = new Broker[Int]
	
.LP Теперь давайте создадим общую очередь для чтения:

	val anyq: Offer[Int] = Offer.choose(q0.recv, q1.recv, q2.recv)
	
.LP <code>anyq</code> является Offer, который будет читать из первой доступной очереди. Обратите внимание, что <code>anyq</code> является <em>все еще синхронизированной</em> - кроме этого у нас еще есть основная очередь. Такая композиция просто не возможна с использованием очередей.
	
#### Пример: Простой пул соединений

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

Используя Offer/Broker, мы можем выразить это вполне естественно:

	class Pool(conns: Seq[Conn]) {
	  private[this] val waiters = new Broker[Conn]
	  private[this] val returnConn = new Broker[Conn]

	  val get: Offer[Conn] = waiters.recv
	  def put(c: Conn) { returnConn ! c }
	
	  private[this] def loop(connq: Queue[Conn]) {
	    Offer.choose(
	      if (connq.isEmpty) Offer.never else {
	        val (head, rest) = connq.dequeue
	        waiters.send(head) { _ => loop(rest) }
	      },
	      returnConn.recv { c => loop(connq enqueue c) }
	    ).sync()
	  }
	
	  loop(Queue.empty ++ conns)
	}

`loop` всегда будет сделкой, чтобы иметь возможность восстановления связи, но только Offer может отправить сообщение, когда очередь не пуста. Использование стойких очередей упрощает дальнейшие рассуждения. Взаимодействие с пулом идет через Offer, поэтому, если вызывающий объект хочет использовать тайм-аут, он может это сделать с помощью комбинаторов:

	val conn: Future[Option[Conn]] = Offer.choose(
	  pool.get { conn => Some(conn) },
	  Offer.timeout(1.second) { _ => None }
	).sync()

Никаких дополнительных телодвижений не требуется для реализации тайм-аутов, это связано с семантикой Offers: если выбран `Offer.timeout`, не требуется больше Offer получать информацию их пула - пул и вызывающая функция никак не могут одновременно получать и отправлять данные, особенно, для `ожидающих` Broker.

#### Пример: Решето Эратосфена

Часто бывает полезно - а иногда и значительно упрощает жизнь - представление параллельных программ в виде набора последовательных процессов, которые взаимодействуют синхронно. Offers и Brokers  предоставляют набор инструментов, чтобы сделать это просто и единообразно. В самом деле, их применение выходит за рамки того, что можно считать "классическими" проблемами параллелизма - параллельное программирование (с помощью Offers/Broker) является полезным *структурированным* инструментом, таким же как подпрограммы, классы и модули.

Одним из этих примеров является [Решето Эратосфена](http://en.wikipedia.org/wiki/Sieve_of_Eratosthenes), который может быть представлен как последовательное применение фильтров для потоков целых чисел. Во-первых, мы должны иметь источник целых чисел:

	def integers(from: Int): Offer[Int] = {
	  val b = new Broker[Int]
	  def gen(n: Int): Unit = b.send(n).sync() ensure gen(n + 1)
	  gen(from)
	  b.recv
	}

.LP <code>integers(n)</code> это просто Offer всех последовательных целых чисел, начиная с <code>n</code>. Затем нужно отфильтровать:

	def filter(in: Offer[Int], prime: Int): Offer[Int] = {
	  val b = new Broker[Int]
	  def loop() {
	    in.sync() onSuccess { i =>
	      if (i % prime != 0)
	        b.send(i).sync() ensure loop()
	      else
	        loop()
	    }
	  }
	  loop()
	
	  b.recv
	}

.LP <code>filter(in, p)</code> возвращает Offer, который извлекает множество простых чисел <code>p</code> из <code>in</code>. В конце концов мы составляем наше решето:

	def sieve = {
	  val b = new Broker[Int]
	  def loop(of: Offer[Int]) {
	    for (prime <- of.sync(); _ <- b.send(prime).sync())
	      loop(filter(of, prime))
	  }
	  loop(integers(2))
	  b.recv
	}

.LP <code>loop()</code> работает просто: он читает следующее (простое) число из <code>of</code>, потом применяет фильтр <code>of</code>, который вытаскивает это число. Так как <code>loop</code> - это рекурсия, то отфильтровывая последовательно простые числа, мы получваем наше решето. Теперь мы можем напечатать первые 10000 простых чисел:

	val primes = sieve
	0 until 10000 foreach { _ =>
	  println(primes.sync()())
	}

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

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

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

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

[Scala]: http://www.scala-lang.org/
[Finagle]: http://github.com/twitter/finagle
[Util]: http://github.com/twitter/util