Композиция функций в JavaScript с Array.prototype.reduceRight

 const compose = (...funcs) => initialArg => funcs.reduce((acc, func) => func(acc), initialArg); 

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

Как мы можем поэтому объединить другие функции в одну функцию более высокого порядка?

 const compose = (...funcs) => initialArg => funcs.reduce((acc, func) => func(acc), initialArg); const log = arg => { console.log(arg); return arg; }; const store = key => arg => { sessionStorage.setItem(key, JSON.stringify(arg)); return arg; }; const getPerson = id => id === 'homer' ? ({ firstName: 'Homer', surname: 'Simpson' }) : {}; const getPersonWithSideEffects = compose( getPerson, log, store('person'), ); const person = getPersonWithSideEffects('homer'); 

В этом коде:

• декларация person будет преобразована в { firstName: 'Homer', surname: 'Simpson' }
• вышеуказанное представление о person будет выведено на консоль браузера
• person будет сериализован как JSON перед записью в хранилище сеанса под ключом person

Важность порядка вызова

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

 const g = x => x + 2; const h = x => x / 2; const i = x => x ** 2; const fNested = x => g(h(i(x))); 

Может показаться естественным повторить это с нашей функцией compose :

 const fComposed = compose(g, h, i); 

В этом случае почему fNested(4) === fComposed(4) значение false ? Возможно, вы помните, как я выделил, как внутренние вызовы интерпретируются первыми, поэтому compose(g, h, i) фактически эквивалентен x => i(h(g(x))) , поэтому fNested возвращает 10 а fComposed возвращает 9 . Мы могли бы просто поменять порядок вызова вложенного или составного варианта f , но, учитывая, что compose предназначен для отражения специфики вложенных вызовов, нам нужен способ уменьшения функций в порядке справа налево; К счастью, JavaScript обеспечивает это с помощью Array.prototype.reduceRight :

 const compose = (...funcs) => initialArg => funcs.reduceRight((acc, func) => func(acc), initialArg); 

В этой реализации fNested(4) и fComposed(4) разрешаются до 10 . Однако наша функция getPersonWithSideEffects теперь неправильно определена; хотя мы можем изменить порядок внутренних функций, существуют случаи, когда чтение слева направо может облегчить умственный анализ процедурных шагов. Оказывается, наш предыдущий подход уже довольно распространен, но обычно его называют трубопроводом :

 const pipe = (...funcs) => initialArg => funcs.reduce((acc, func) => func(acc), initialArg); const getPersonWithSideEffects = pipe( getPerson, log, store('person'), ); 

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

Композиция функций как альтернатива наследования

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

 class Storable { constructor(key) { this.key = key; } store() { sessionStorage.setItem( this.key, JSON.stringify({ ...this, key: undefined }), ); } } class Loggable extends Storable { log() { console.log(this); } } class Person extends Loggable { constructor(firstName, lastName) { super('person'); this.firstName = firstName; this.lastName = lastName; } debug() { this.log(); this.store(); } } 

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

 class State extends Storable { store() { return fetch('/api/store', { method: 'POST', }); } } class MyState extends State {} 

Если бы нам нужно было создать экземпляр MyState и вызвать его метод store , мы бы не стали Storable метод store Storable если бы мы не добавили вызов super.store() в MyState.prototype.store , но тогда это создаст жесткий, хрупкий метод. связь между State и Storable . Это можно смягчить с помощью систем сущностей или шаблона стратегии, как я уже упоминал в другом месте , но, несмотря на силу наследования, выражающую более широкую таксономию системы, композиция функций обеспечивает плоское, лаконичное средство совместного использования кода, которое не зависит от имен методов.

Резюме

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