«Функциональное программирование», «Immutable значения», «Pure функции».
Тоже слышал эти умные слова?

И ты такой: «Что? Можно просто for написать?»

Спокойно. Сейчас все разложим по полочкам. Даже если ты пишешь var a = 1 и гордишься этим - ты свой. Погнали.

Многие думают, что функциональный стиль это просто когда ты используешь map, filter, reduce и чувствуешь себя умным. Типа, "я же не пишу for, значит я уже в functional game". И это…правда. Но только частично.

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

Функциональный стиль (Functional Programming) - такой подход, где:

• функции как блоки Лего: склеиваешь, передаешь, тасуешь;

• данные не меняются (immutable);

• функции честные, без сюрпризов - всегда выдают одно и то же (pure);

• ты не говоришь «делай цикл», а говоришь «вот что я хочу» (declarative).

Выглядит красиво, звучит страшно. По факту — просто удобно.

Тезис 1: все через map, filter, reduce

Да-да, вот эти магические штуки:

let numbers = [1, 2, 3, 4, 5]

let squares = numbers.map { $0 * $0 }       // [1, 4, 9, 16, 25]
let evens = numbers.filter { $0 % 2 == 0 }  // [2, 4]
let sum = numbers.reduce(0, +) 			    // 15

Перевод на человеческий:
- map: обработай каждую штуку;
- filter: убери лишнее;
- reduce: собери все в одну кучу.

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

Меньше циклов, меньше багов, больше кайфа.

Тезис 2: let - это любовь

Если ты все еще на var, как на сигаретах - пора бросать.

let name = "Pepe"
// name = "Froggy" // Ага, получай ошибку

Чем меньше ты меняешь - тем меньше ты ломаешь.

let - твой друг. var - бывший, которого пора отпустить.

Тезис 3: Чистые функции (pure) как хороший друг — не подставит

func double(_ x: Int) -> Int {
    x * 2
}

- всегда честно возвращает одно и то же;
- не печатает в консоль;
- не трогает глобальные переменные.
Просто делает свою работу.

Противоположность:

func randomize(_ x: Int) -> Int {
    x * Int.random(in: 1...10)
}

Это уже мутный тип. Как начальник, который обещал повышение.

Тезис 4: Функции как значения (Higher-order functions)

func add(_ a: Int, _ b: Int) -> Int {
    a + b
}

let operation: (Int, Int) -> Int = add
operation(3, 4) // 7

Функции как карты в колоде. Комбинируй, передавай, твори.

Тезис 5: Композиция (composition) - склеивание функций

Маленькие функции можно собрать в одну большую. Как бутерброд.

func double(_ x: Int) -> Int { x * 2 }
func increment(_ x: Int) -> Int { x + 1 }

let result = { double(increment($0)) }
result(3) // 8

Чем проще куски, тем проще их переставлять.

Тезис 6: Типы-значения (value types) > ссылочные (reference types)

Когда ты работаешь со struct (а не с class), ты меньше паришься, кто где что поменял. Каждое изменение - новая копия. Никто не ломает твою память.

struct Point {
    let x: Int
    let y: Int
}

Ты - хозяин объекта, а не какой-то левый ViewController, который взял и поменял тебе «x» в 3 часа ночи.

Тезис 7: Опционалы, Result и map - цепочки без боли

В Swift есть типы, которые позволяют строить цепочки операций, но только если все идет хорошо.

let number: Int? = 5
let doubled = number.map { $0 * 2 } // 10?

Если number - nil, функция внутри map даже не вызовется.

То же самое с Result:

enum MyError: Error {
    case oops
}

let badResult: Result<Int, Error> = .failure(MyError.oops)
let squared = badResult.map { $0 * $0 }

А если Result  это .failure?
Тогда map просто пройдет мимо, не тронув ошибку.

Это как конвейер: если деталь бракованная - просто не обрабатываем, а едем дальше. Никаких истерик.

map, flatMap и другие…позволяют писать код без if let, guard, switch. Они аккуратно работают только с "нормальными" значениями и не трогают плохие.

Знаешь, кто реально кайфует от функционального и декларативного подхода?
Твой любимый SwiftUI.

Он буквально кричит:
"Забудь ты свои UIView, забудь свой delegate, просто скажи, что ты хочешь - и я все сделаю".

struct HelloView: View {
    var body: some View {
        Text("Привет, мир!")
            .font(.title)
            .foregroundColor(.blue)
            .padding()
    }
}

Никаких layoutSubviews(), addSubview() и прочего душного кода. Ты просто описываешь результат, а не процесс. Вот это и есть декларативный стиль.

body - функция, возвращающая описание интерфейса -> pure.
цепочки .font(.title).foregroundColor(.blue).padding() -> чистейший function chaining.

Функциональный стиль это не про "быть модным".

Это про:

• меньше багов;

• меньше головной боли;

• меньше var, for, if let, guard let.

Это как писать код, который сам себя объясняет.

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

Там я делаю тестовое задание на джуна, где надо:

• построить граф;

• пройтись по нему (DFS);

• построить остовное дерево;

• применять паттерны проектирования;

• не забывать про ООП.

Впервой части я писал «чтобы работало».
А во второй — рефакторинг. Переписываем все в функциональном стиле, аккуратно, по‑человечески.

Пример из тестового

На этапе генерации карты нужно было создать массив всех возможных координат комнат.

Типа:

• пройтись по всем y;

• внутри по всем x;

• для каждой пары (x, y) создать Position.

В императивном стиле это выглядело бы так:

for y in 1...mapSize.height {
    for x in 1...mapSize.width {
        positions.append(Position(x: x, y: y))
    }
}

Работает? Да.
Красивая ли это жизнь? Не очень.

Теперь функциональная версия:

let positions = (1...mapSize.height).flatMap { y in
    (1...mapSize.width).map { x in Position(x: x, y: y) }
}

flatMap разворачивает двумерную структуру в плоский массив.
map создает Position для каждой координаты.

Все без единого var, append и посторонних слов.

Второй пример

Задача: прорубить двери между комнатами, чтобы получилась связная карта.
Каждая комната - вершина графа, возможные двери - ребра.
На входе словарь rooms: [Position: Room], по сути самый настоящий граф.
Вот тебе задание: построить остовное дерево (spanning tree) и соединить комнаты.

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

Работает? Да.
Надежно? Ну…как почтальон, который вскрывает письма.

А потом я подумал: "А давай без боли?"
Переписал на функциональный манер:

func buildSpanningTree(from rooms: [Position: Room]) -> [Position: Room] {
    // возвращает новый словарь с нужными дверями
}

Теперь метод ничего не трогает и ничего не портит.
Он просто принимает данные, делает магию и возвращает результат.

Граф больше не страдает. Он не знал, что над ним делали DFS.
Все чисто, по согласию: один граф на вход, другой на выход.

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

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

Ты все еще можешь любить классы, ООП и даже иногда писать for.
Но когда попробуешь map, flatMap, pure и immutable, назад будет тяжело.

Это как впервые попробовать нормальный кофе. Вроде то же самое, но жить веселее.