Это означает:

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

Год появления: 1958 (с появлением Lisp)

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

Пример на Rust (итераторы):

fn main() {
    let numbers = vec![1, 2, 3, 4];
    let sum_of_squares: i32 = numbers.iter()
        .map(|x| x * x)
        .sum();
}

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

1. Неизменяемость данных

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

2. Чистые функции

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

fn sum(a: usize, b: usize) -> usize {
    return a + b;
}

3. Композиция функций

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

fn multiply_by_two(x: i32) -> i32 {
    x * 2
}
fn add_three(x: i32) -> i32 {
    x + 3
}
// Функция-композитор: принимает две функции и возвращает новую
fn compose<F, G>(f: F, g: G) -> impl Fn(i32) -> i32
where
    F: Fn(i32) -> i32,
    G: Fn(i32) -> i32,
{
    move |x| f(g(x))
}
fn main() {
    // Создаём композицию: сначала multiply_by_two, потом add_three
    let multiply_then_add = compose(add_three, multiply_by_two);

    let value = 5;
    println!("Результат: {}", multiply_then_add(value)); // (5 * 2) + 3 = 13
}

4. Функции высшего порядка

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

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

fn add(x: usize) -> usize {
    // Это выводится, так как функции оцениваются в первую очередь
    println!("executing add"); 
    return x + x;
}
fn multiply(x: usize) -> usize {
    // Это выводится, так как функции оцениваются в первую очередь
    println!("executing multiply"); 
    return x * x;
}
fn add_or_multiply(add: bool, on_add: usize, on_multiply: usize) -> usize {
    if add {
        on_add
    } else {
        on_multiply
    }
}
fn main() {
    println!("{}", add_or_multiply(true, add(4), multiply(4))); // 8
    println!("{}", add_or_multiply(false, add(4), multiply(4))); // 16
}

Это даст следующий вывод, и мы видим, что обе функции выполняются всегда

executing add
executing multiply
8
executing add
executing multiply
16

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

fn add(x: usize) -> usize {
    // это печатается, поскольку функции оцениваются первыми
    println!("executing add"); 
    return x + x;
}
fn multiply(x: usize) -> usize {
    // это печатается, поскольку функции оцениваются первыми
    println!("executing multiply"); 
    return x * x;
}
type FnType = fn(t: usize) -> usize;

// Теперь это функция высшего порядка, поэтому оценка функций задерживается в if-else
fn add_or_multiply(add: bool, on_add: FnType, on_multiply: FnType, t: usize) -> usize {
    if add {
        on_add(t)
    } else {
        on_multiply(t)
    }
}
fn main() {
    println!("{}", add_or_multiply(true, add, multiply, 4)); // 8
    println!("{}", add_or_multiply(false, add, multiply, 4)); // 16
}

Это выводит то, что ниже, и мы можем видеть, что были выполнены только необходимые функции!

executing add
8
executing multiply
16

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

use std::collections::HashMap;
fn main() {
    let mut cached_added = HashMap::new();
    let mut add = |x: usize| -> usize {
        return match cached_added.get(&x) {
            Some(&val) => val,
            _ => {
                println!("{}", "executing add");
                let out = x + x;
                cached_added.insert(x, out);
                out
            }
        };
    };
    let mut cached_multiplied = HashMap::new();
    let mut multiply = |x: usize| -> usize {
        return match cached_multiplied.get(&x) {
            Some(&val) => val,
            _ => {
                println!("executing multiply");
                let out = x * x;
                cached_multiplied.insert(x, out);
                out
            }
        };
    };
    fn add_or_multiply(add: bool, on_add: usize, on_multiply: usize) -> usize {
        if add {
            on_add
        } else {
            on_multiply
        }
    }
    println!("{}", add_or_multiply(true, add(4), multiply(4))); // 8
    println!("{}", add_or_multiply(false, add(4), multiply(4))); // 16
}

5. Рекурсия

Рекурсия - это процесс, при котором функция вызывает саму себя. В функциональном программировании рекурсия является основным способом повторения операций. Она позволяет создавать более элегантный и краткий код.

Функциональное программирование способствует рекурсии по циклу. Давайте посмотрим пример для вычисления факториала числа.

В традиционном итеративном подходе:

fn main() {
    fn factorial(mut num: usize) -> usize {
        let mut result = 1;
        while num > 0 {
            result *= num;
            num = num - 1;
        }
        return result;
    }

    println!("{}", factorial(20)); // 2432902008176640000
}

То же самое можно сделать с помощью рекурсии:

fn main() {
    fn factorial(num: usize) -> usize {
        return match num {
            0 => 1,
            _ => num * factorial(num - 1),
        };
    }

    println!("{}", factorial(20)); // 2432902008176640000
}

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

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

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

Зачем нужен карринг

• Частичное применение функций — можно заранее зафиксировать часть аргументов, а остальные передавать позже.

• Повышение переиспользуемости кода — одна универсальная функция превращается в набор более специализированных.

• Чистота и читаемость — особенно полезно в цепочках функционального стиля.

fn add(x: i32) -> impl Fn(i32) -> i32 {
    move |y| x + y
}

let add5 = add(5); // функция, которая прибавляет 5
println!("{}", add5(3)); // 8

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

1. Управление сложностью (Managing Complexity): По мере роста программ, в процедурном подходе возникала проблема "спагетти-кода". Все данные были доступны глобально, и функции могли изменять их в любом месте, что затрудняло отслеживание изменений и предсказание поведения программы. ООП предложил способ модуляризации кода. Вместо набора функций, оперирующих глобальными данными, появились "объекты", которые инкапсулируют (объединяют) данные и функции, работающие с этими данными. Это делает части программы более независимыми и легче управляемыми.

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

3. Инкапсуляция (Encapsulation): В процедурном программировании данные часто были доступны напрямую, что позволяло любой части программы изменять их. Это могло приводить к непредсказуемым ошибкам. ООП позволяет инкапсулировать данные внутри объекта, делая их доступными только через определенные методы (интерфейс объекта). Это называется упаковкой информации. Таким образом, внутреннее состояние объекта защищено от некорректных изменений извне, что повышает надежность и упрощает отладку.

4. Реальное моделирование (Modeling Real-World Entities): В реальном мире мы мыслим объектами: машина, человек, счет в банке. У каждого объекта есть свои характеристики (данные) и действия, которые он может выполнять (поведение). ООП позволяет напрямую моделировать эти реальные сущности в коде, делая программу более интуитивной и легкой для понимания. Объект "Машина" может иметь свойства "цвет", "скорость" и методы "завести", "остановить".

5. Полиморфизм (Polymorphism): ООП позволяет объектам разных классов реагировать по-разному на одно и то же сообщение (вызов метода). Например, у вас может быть базовый класс "Фигура" и производные классы "Круг" и "Квадрат". У всех них может быть метод "нарисовать()", но каждый будет реализовывать его по-своему. Это делает код более гибким и расширяемым.

Конкретная проблема ООП, решаемая в ESR:

Жёсткая связь между состоянием и поведением

В классическом ООП поведение (методы) жёстко привязано к данным (полям класса), что приводит к:

1. Раздутым классам – объекты берут на себя слишком много ответственностей.
2. Сложности изменения поведения – если нужно изменить логику, приходится модифицировать классы или создавать сложные иерархии наследования/композиции.
3. Проблемам с тестированием – из-за мутаций состояния и скрытых зависимостей.

Как ESR решает эту проблему?

ESR разделяет:

• Сущности (Entity) – просто контейнеры для данных (без логики).
• Состояние (State) – данные, связанные с сущностью.
• Реакции (React) – отдельные функции, обрабатывающие состояние.

Это даёт:

• Гибкость – поведение можно менять, не трогая структуру данных.
• Простота тестирования – реакции (чистые или детерминированные функции) легко тестируются.
• Меньше boilerplate-кода – не нужны сложные паттерны вроде Visitor или Strategy.

Пример сравнения:

❌ В ООП (проблема):

class User {
    private String name;
    private int balance;

    // Жёстко привязанное поведение
    public void addMoney(int amount) {
        this.balance += amount;
    }
}

Если нужно изменить логику начисления, придётся менять класс User.

✅ В ESR (решение):

// Данные
const user = { name: "Alice", balance: 100 };

// Отдельная функция-реакция
function addMoney(user, amount) {
    return { ...user, balance: user.balance + amount };
}

Логика изменяется без модификации структуры user.

Когда ESR нужен:

• Для сложных предметных областей, где поведение зависит от многих факторов
• Когда нужно гибко комбинировать компоненты (как в ECS в gamedev)
• Когда поведение должно работать с множеством разных сущностей

Вывод:

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