Функциональный стиль: объясняю как другу

«Функциональное программирование», «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, назад будет тяжело.

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