Слово на букву «М», или Монады уже здесь08.07.2015 11:18

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

Такой интерфейс Optional позволяет выстраивать вызовы в цепочки, например, следующим образом:

return Optional.of(employee)
        .map(Employee::getPerson)
        .map(Person::getAddress)
        .map(Address::getStreet)
        .orElse("<неизвестно>");

Выглядит чуть компактнее, чем в предыдущем примере. Но плюсы на этом не заканчиваются. Во-первых, мы убрали из кода всю шелуху, не относящуюся к делу — мы выполнили несколько простых действий с объектом employee, описав их в коде явно и без лишнего вспомогательного кода. Во-вторых, мы можем быть уверены в отсутствии NPE, если где-то на пути этой цепочки встретится null-значение — Optional уберегает нас от этого. В-третьих, полученная конструкция является выражением (а не утверждением, как конструкция if из предыдущего примера), а значит, возвращает значение — следовательно, её значительно легче композировать с другим кодом.

Итого, как же мы решили проблему потенциального отсутствия объекта с помощью типа Optional?

1. Обозначили явно проблему в типе объекта (Optional).
2. Спрятали весь вспомогательный код (проверка на отсутствие объекта) внутрь этого типа.
3. Передали типу набор простых стыкующихся действий.

Что здесь понимается под «стыкующимися действиями»? А вот что: метод Person: getAddress принимает на вход объект типа Person, полученный как результат предыдущего метода Employee: getPerson. Ну, а метод Address: getStreet, соответственно, принимает результат предыдущего действия — вызова метода Person: getAddress.

А теперь — главное: Optional в Java — это не что иное, как реализация паттерна монады.

Проблема: итерация

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

List employeeNames = new ArrayList<>();
for (Company company : companies) {
    for (Department department : company.getDepartments()) {
        for (Employee employee : department.getEmployees()) {
            employeeNames.add(employee.getName());
        }
    }
}

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

В Java 8 появился целый новый API, позволяющий более удобно работать с коллекциями. Основным интерфейсом этого API является интерфейс java.util.stream.Stream, содержащий в себе, в числе прочего, методы, которые могут показаться знакомыми из предыдущего примера:

public interface Stream extends BaseStream> {

     Stream map(Function mapper);

     Stream flatMap(Function> mapper);

}

Действительно, метод map, как и в случае с Optional, принимает на вход функцию, трансформирующую объект, применяет её ко всем элементам коллекции, а возвращает очередной Stream из полученных трансформированных объектов. Метод flatMap принимает функцию, которая сама по себе возвращает Stream, и сливает все полученные при преобразовании потоки в единый Stream.

С использованием Streams API код итерации можно переписать вот так:

List streamEmployeeNames = companies.stream()
        .flatMap(Company::getDepartmentsStream)
        .flatMap(Department::getEmployeesStream)
        .map(Employee::getName)
        .collect(toList());

Здесь мы немного схитрили, чтобы обойти ограничения Streams API в Java — к сожалению, они не замещают собой существующие коллекции, а являются целой параллельной вселенной функциональных коллекций, порталом в которую является метод stream (). Поэтому каждую полученную в ходе обработки данных коллекцию мы должны ручками проводить в эту вселенную. Для этого мы добавили в классы Company и Department геттеры для коллекций, которые сразу преобразуют их в объекты типа Stream:

static class Company {

    private List departments;

    public Stream getDepartmentsStream() {
        return departments.stream();
    }

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

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

1. Обозначили явно проблему в типе объекта (Stream).
2. Спрятали весь вспомогательный код (итерация по элементам и вызов переданной функции над ними) внутрь этого типа.
3. Передали объекту этого типа набор простых стыкующихся действий.

Подытожим: интерфейс Stream в Java — это реализация паттерна монады.

Проблема: асинхронные вычисления

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

Thread thread1 = new Thread(() -> {
    String string = "Hello" + " world";
});

Thread thread2 = new Thread(() -> {
    int count = "Hello world".length();
});

У нас есть два отдельных потока, в которых мы хотим выполнить вычисления, причём вычисления в потоке thread2 должны производиться над результатом вычислений в потоке thread1. Я даже не буду пытаться привести здесь код синхронизации потоков, который заставит эту конструкцию работать — кода будет много, а главное, он будет плохо композироваться, когда таких блоков вычислений будет множество. А ведь мы хотели всего лишь выполнить последовательно друг за другом два простых действия —, но асинхронность их выполнения путает нам все карты.

Чтобы побороть излишнюю сложность, ещё в Java 5 появились футуры (Future), позволяющие организовывать блоки многопоточных вычислений в цепочки. К сожалению, в классе java.util.concurrent.Future мы не найдём знакомых нам методов map и flatMap — он не реализует монадический паттерн (хотя его реализация CompletableFuture подбирается к этому достаточно близко). Поэтому здесь мы опять немного схитрим и выйдем за пределы Java, а попытку представить, как бы выглядел интерфейс Future, появись он в Java 8, оставим в качестве домашнего задания читателям. Рассмотрим интерфейс трейта scala.concurrent.Future в стандартной библиотеке языка Scala (сигнатура методов несколько упрощена):

trait Future[+T] extends Awaitable[T] {

  def map[S](f: T => S): Future[S]

  def flatMap[S](f: T => Future[S]): Future[S]

}

Если приглядеться, методы очень знакомые. Метод map применяет переданную функцию к результату выполнения футуры — когда этот результат будет доступен. Ну, а метод flatMap применяет функцию, которая сама возвращает футуру — таким образом, эти две футуры можно объединить в цепочку с помощью flatMap:

val f1 = Future {
  "Hello" + " world"
}

val f2 = { s: String =>
  Future {
    s.length()
  }
}

Await.ready(

  f1.flatMap(f2)
    .map(println),

  5.seconds
)

Итак, как же мы решили проблему выполнения асинхронных взаимозависимых блоков вычислений?

1. Обозначили явно проблему в типе объекта (Future[String]).
2. Спрятали весь вспомогательный код (вызов следующей по цепочке футуры по окончании предыдущей) внутрь этого типа.
3. Передали объекту этого типа набор простых стыкующихся действий (футура f2 принимает объект такого типа (String), который возвращает футура f1).

Можно резюмировать, что Future в Scala также реализует паттерн монады.

Итоги

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

Для более глубокого погружения в тему рекомендую следующие ресурсы:

© Habrahabr.ru