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

Это серия статей о функциональном программировании:

1. Парадигмы программирования
2. Композиция
3. Функторы
4. Каррирование (рассматривается в этой статье)
5. Чистые функции
6. Функции первого класса

Что такое каррирование?

Каррированная функция — это функция, которая продолжает возвращать функции до тех пор, пока не будут отправлены все ее параметры.

Как работает каррирование?

Предположим, есть функция сложения add.

const add = (a, b) => a + b

Простейшая реализация каррирования — заставить функцию возвращать функцию и т. д.

const add = (a) => (b) => a + b

Эту функцию можно использовать так.

const addOne = add(1) // addOne = (b) => 1 + b

Представим, что у нас есть функция curry, которая принимает функцию и каррирует ее.

const add = curry((a, b) => a + b)

Как мы видим, curry — это функция, которая использует другую функцию для ленивой обработки параметров. Итак, теперь мы можем вызвать ее следующим образом.

const addOne = add(1) // addOne = (b) => 1 + b

Итак, сначала мы создали addOne, передав 1 в качестве первого параметра (a) каррированной функции добавления. Что привело к другой функции, которая ожидает остальные параметры, где логика добавления не будет выполняться, пока не будут предоставлены все параметры.

addOne(2) // 3

Теперь, передавая 2 (как b) в addOne выполняет логику 1 + 2.

Пояснение к функции curry

Функция curry принимает функцию и делает ее параметры ленивыми, другими словами, вы предоставляете эти параметры по мере необходимости. Так же, как addOne. Вы по-прежнему можете вызывать каррированную версию функции добавления следующим образом.

const three = add(1, 2)

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

Для чего нужно каррировать функции?

Каррирование делает код:

• Чище
• Уменьшает количество повторяющихся параметров и делает код более лаконичным
• Более компонуемым
• Переиспользуемым

Почему каррирование делает код лучше?

Некоторые функции принимают конфигурацию в качестве входных данных

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

const translate = (locale, text) => { /* логика перевода */ }

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

translate('ru', 'Hello')
translate('ru', 'Goodbye')
translate('ru', 'How are you?')

Каждый раз, когда мы вызываем translate, мы должны указывать язык и текст. Что является избыточным для предоставления локали при каждом вызове. Но вместо этого давайте каррируем translate следующим образом.

const translate = curry(
  (locale, text) => { /* логика перевода */ }
)

const translateToRu = translate('ru')

Теперь translateToRu имеет ru в качестве locale, предоставленного каррированной функции translate, и ожидает текста. Мы можем использовать это так.

translateToRu('Hello')
translateToRu('Goodbye')
translateToRu('How are you?')

Каррирование действительно внесло улучшения, нам не нужно каждый раз указывать локаль. Вместо этого каррированная функция translateToRu содержит locale из-за каррирования. После каррирования - в этом конкретном примере код стал:

• чище
• менее многословным и менее избыточным.

Потому что мы отделили конфигурацию от фактических данных. Что очень удобно во многих случаях.

На практике

На практике у нас есть динамическая локаль (у каждого пользователя свой язык), может быть fr, en, de или что-то еще. Поэтому вместо этого лучше переименовать translateToRu в translateTo, где translateTo может быть загружен с любой локалью. Теперь у нас есть translate, который принимает locale как конфигурацию и text как данные. Благодаря тому, что translate каррирован, мы смогли отделить параметры конфигурации от данных.

Зачем отделять конфигурации от данных?

Многие компоненты и функции нуждаются в использовании некоторой функциональности (в нашем случае, translateTo), но не должны или не могут знать о части конфигурации (locale). Эти компоненты или функции имеют только часть данных (text). Таким образом, эти функции смогут использовать эту функцию без необходимости знать о части конфигурации. Таким образом, этот компонент или функция будут меньше связаны с системой, что сделает компоненты более компонуемыми и более удобными в сопровождении.

Когда применять каррирование?

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

Связь между замыканием и каррированием

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

Примеры каррирования

Перед тем как продолжить

Добавим некоторые утилиты, чтобы мы могли перейти к примерам. Прототип массива имеет такие утилиты, как filter, map и другие. Но они не поддерживают каррирование, потому что используют запись через точку (.). Итак, давайте конвертируем их в каррируемый формат.

const filter = (fn, list) => list.filter(fn)
const map = (fn, list) => list.map(fn)
const startsWith = (starter, s) => s.startsWith(starter)

Теперь мы можем использовать их так.

const lessThan21 = user => user.age < 21

// Вместо такого использования...
const filteredUsers = users.filter(lessThan21 )

// ...будем использовать такое
const filteredUsers = filter(lessThan21, users)

Мы исключили запись через точку и передали обработанные данные в качестве последнего параметра. Затем мы их каррируем. Функция curry будет принимать функцию и возвращать каррированную функцию.

const filter = curry((fn, list) => list.filter(fn))
const map = curry((fn, list) => list.map(fn))
const startsWith = curry((starter, s) => s.startsWith(starter))

Пример 1

Дан список чисел, нужно увеличить все числа на 1. Вход: [1, 2, 3, 4, 5] Выход: [2, 3, 4, 5, 6] Реализация:

// каррированная функция add была определена ранее
const addOne = add(1)
const incrementNumbers = map(addOne)
const incrementedNumbers = incrementNumbers(numbers)

Пример 2

Дана строка, оставить все слова, начинающиеся с буквы c. Вход: "currying javascript function” Выход: “currying” Реализация:

const startsWithC = startsWith('c')
const filterStartsWithC = filter(startsWithC)
const filteredWords = filterStartsWithC(words)

Пример 3

Дан список диапазонов и список чисел. Создайте массив функций, которые могут фильтровать числа на основе предоставленных диапазонов.

const ranges = [
  { min: 10, max: 100 }, 
  { min: 100, max: 500 }, 
  { min: 500, max: 999 }
]
const numbers = [30, 50, 110, 200, 650, 700, 1000]
// 30 и 50 в первом диапазоне
// 110 и 200 во втором диапазоне
// 650 и 700 в третьем диапазоне
// 1000 не принадлежит ни одному диапазону

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

const isInRange = curry(
  (range, val) => val > range.min && val < range.max
)

const filters = ranges.map((range) => filter(isInRange(range)))

В этом примере есть двойное каррирование, filter и isInRange. filters теперь представляют собой список функций, каждая из которых ожидает numbers для обработки.

Для лучшего понимания можно развернуть каррирование и вместо этого использовать обычные функции.

const isInRange = (range, val) => val > range.min && val < range.max

const filters = ranges.map(
  (range) => (numbers) => numbers.filter(
    number => isInRange(range, number)
  )
)

Итоги

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

Это серия статей о функциональном программировании:

1. Парадигмы программирования
2. Композиция
3. Функторы (рассматривается в этой статье)
4. Каррирование
5. Чистые функции
6. Функции первого класса

Что такое функтор?

Функтор (functor) это:

• обертка над значением,
• предоставляет интерфейс для преобразование (map),
• подчиняется законам функтора (поговорим о них позже).

Примеры функторов

• Массив (Array),
• Промис (Promise).

Почему массив - функтор?

Вспомним определение функтора:

• обертка над списком значений,
• предоставляет интерфейс для преобразования - метод map,
• подчиняется законам функтора.

[1, 2, 3]      // обернутое значение
  .map(        // интерфейс для преобразования значения
    x => x * 2
  )

Почему промис - функтор?

Промис это:

• обертка над любым значением из JavaSctipt типов,
• предоставляет интерфейс для преобразования - метод then,
• подчиняется законам функтора.

const promise = new Promise((resolve, reject) => {
  resolve(
    { data: "value" } // обернутое значение, в данном случае объект
  )
});
 
promise
  .then(              // интерфейс для преобразования значения
    response => console.log(response)
  );

Что объединяет массив (или промис) и функтор?

Функтор - это паттерн проектирования, а Array и Promise - типы данных, которые основаны на этом паттерне.

Почему мы говорим, что массив и промис - функторы?

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

Где использовать функторы?

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

{
  products: [
    {
      name: "All about JavaScript",
      type: "book",
      price: 22,
      discount: 20
    }
  ]
}

Постановка задачи

Найти финальную цену первого товара с учетом скидки. Если по какой-либо причине будут переданы неправильные данные, вывести строку "No data".

Шаги алгоритма

1. Найти первый продукт со скидкой,
2. Применить скидку,
3. Продолжать проверку данных на валидность. Если данные не валидны - вернуть "No data".

Традиционное решение

const isProductWithDiscount = product => {
  return !isNaN(product.discount)
}
const findFirstDiscounted = products => {
  products.find(isProductWithDiscount)
}
 
const calcPriceAfterDiscount = product => {
  return product.price - product.discount
}
 
const findFinalPrice = (data, fallbackValue) => {
  if(!data || !data.products) return fallbackValue
 
  const discountedProduct = findFirstDiscounted(data.products)
  if(!discountedProduct) return fallbackValue
 
  return calcPriceAfterDiscount(discountedProduct)
}
 
findFinalPrice(data, "No data")

Комментарии к традиционному решению

Достоинства:

• Атомарные логические единицы (isProductWithDiscount, findFirstDiscounted и calcPriceAfterDiscount),
• Логику защищена от невалидных данных.

Что можно улучшить:

• Cлишком много защитных проверок. (Защитное программирование (Defensive programming) является обязательным в любом отказоустойчивом программном обеспечении. Однако, в нашем коде 50% тела функции findFinalPrice — проверка на валидность данных. Это слишком много).
• fallbackValue почти везде.

Почему нас волнуют эти улучшения?

Потому что данный код заставляет слишком в него вникать. Это негативно влияет на DX (Developer Experience) - уровень удовлетворенности разработчика от работы с кодом. Проанализируем код, чтобы прийти к лучшему решению. Части, которые мы стремимся улучшить, формируют паттерны (защита (defence) и откат (fallback)). Хорошо то, что эти части на самом деле цельные и атомарные. Мы должны иметь возможность абстрагировать этот паттерн в оболочку, которая могла бы обрабатывать эти крайние случаи вместо нас. Обертка позаботится о крайних случаях, а нам останется позаботиться только о бизнес-логике.

Функтор Maybe

Как мы обсуждали ранее, нам нужна только обертка, которая абстрагируется от обработки данных. Итак, роль функтора Maybe состоит в том, чтобы обернуть наши данные (потенциально невалидные данные) и обработать для нас крайние случаи.

Имплементация функтора Maybe

function Maybe(value) {
  const isNothing = () => {
    return value === null || value === undefined
  }
  
  const map = (fn) => {
    return isNothing() ? Maybe() : Maybe(fn(value))
  }
 
  const getValueOrFallback = {
    return (fallbackValue) => isNothing() ? fallbackValue : value;
  }
 
  return {
    map,
    getValueOrFallback,
  };
}

Пояснения к имплементации

• isNothing проверяет валидно ли обернутое в функтор Maybe значение
• map - интерфейс для преобразования обернутого значения, с помощью которого мы применяем функции с бизнес логикой к обернутому значению. map возвращает новое значение в другом экземпляре Maybe. Таким образом, мы можем сделать цепочку вызовов map - .map().map().map....
• getValueOrFallback возвращает обернутое значение или запасное значение fallbackValue.

Как использовать функтор Maybe?

С валидными данными:

Maybe('Hello')
  .map(x => x.substring(1))
  .getValueOrFallback('fallback') // 'ello'

С невалидными данными:

Maybe(null)
  .map(x => x.substring(1))       // функция не будет запущена
  .getValueOrFallback('fallback') // 'fallback'

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

Решение задачи с функтором Maybe

const isProductWithDiscount = product => {
  return !isNaN(product.discount)
}
const findFirstDiscounted = products => {
  return products.find(isProductWithDiscount)
}
const calcPriceAfterDiscount = product => {
  return product.price - product.discount
}
 
Maybe(data)
 .map((x) => x.products)
 .map(findFirstDiscounted)
 .map(calcPriceAfterDiscount)
 .getValueOrFallback("No data")

Комментарии к решению с функтором Maybe

Мы смогли улучшить традиционное решение при помощи функтора Maybe:

• мы не защищаем код сами, вместо нас это делает функтор Maybe,
• мы указали fallbackValue только один раз.

Как функтор Maybe соответствует определению функтора? Функтор Maybe это:

1. обертка над любым значением из JavaScript типов,
2. предоставляет интерфейс для преобразования - метод map,
3. подчиняется законам функтора.

Законы функторов

Закон идентичности (Identity law)

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

const m1 = Maybe(value)
const m2 = Maybe(value).map(v => v)
// m1 и m2 эквивалентны

Закон композиции (Composition law)

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

const m1 = Maybe(value).map(v => f(g(v)))
const m2 = Maybe(value).map(v => g(v)).map(v => f(v))
// m1 и m2 эквивалентны

Зачем использовать функторы?

• Абстракция над применением функции,
• Усиление композиции функций,
• Уменьшение количества защитного кода (как в функторе Maybe),
• Более чистая структура кода,
• Переменные более явно указывают на то, что мы ожидаем (что Maybe моделирует значение, которое может присутствовать, а может и не присутствовать).

Что означает Абстракция над применением функции?

То, что мы передаем функцию (т.е. x => x.products) в интерфейс преобразования (т.е. map) обертки (т.е. Maybe), и она знает, как позаботиться о себе (посредством своей внутренней реализации). Нас не интересуют детали реализации оболочки, которые она содержит (детали реализации скрыты), и тем не менее мы знаем, как использовать обертку (Array или Promise), используя их интерфейсы преобразования (map). И это на самом деле крайне важно в мире программирования. Это снижает планку того, как много мы, как программисты, должны понимать, чтобы иметь возможность что-то сделать. Функторы могут быть реализованы на любом языке, поддерживающем функции высшего порядка (а таких в наши дни большинство).

Почему функторы не используются повсеместно?

Просто потому, что мы к ним не привыкли. До .map (и .then) мы мутировали массивы или перебирали их значения вручную. Но как только мы обнаружили .map, мы начали адаптировать его в качестве нового инструмента преобразования. Я надеюсь, что, поняв ценность функторов, мы начнем чаще внедрять их в наши ежедневные задачи как привычный инструмент. Функтор Maybe - лишь пример функтора. Существует множество функторов, которые выполняет различные задачи. В этой статье мы рассмотрели самый простой из них, чтобы понять саму идею функторов.

Итоги

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