Programowanie funkcyjne bez strachu: wprowadzenie do Scali i Elixira krok po kroku

Po co w ogóle programowanie funkcyjne? Kontekst i motywacja

Imperatywne, obiektowe i funkcyjne – trzy spojrzenia na ten sam problem

Najłatwiej poczuć różnicę między podejściem imperatywnym, obiektowym a funkcyjnym na prostym, bliskim biznesowi przykładzie. Załóżmy, że istnieje lista zamówień i trzeba:

• odfiltrować zamówienia anulowane,
• policzyć łączną wartość aktywnych zamówień,
• zwrócić wynik jako liczbę.

W klasycznym stylu imperatywnym (np. pseudo‑Java) kod często wygląda tak:

// styl imperatywny (pseudokod)
double total = 0.0;
for (Order o : orders) {
    if (!o.isCancelled()) {
        total = total + o.getAmount();
    }
}
return total;

Tu wszystko kręci się wokół zmiennego stanu: zmienna total jest wielokrotnie modyfikowana. Program mówi komputerowi jak coś zrobić (krok po kroku), zamiast opisywać co ma zostać policzone.

W podejściu obiektowym jako główni bohaterowie pojawiają się obiekty, które „wiedzą” jak przetwarzać dane, np.:

class OrdersCalculator {
    double calculateTotal(List<Order> orders) {
        return orders.stream()
                     .filter(o -> !o.isCancelled())
                     .mapToDouble(Order::getAmount)
                     .sum();
    }
}

Tutaj widać już zbliżenie do programowania funkcyjnego: pojawiają się funkcje (lambdy), przetwarzanie kolekcji i brak ręcznie modyfikowanego licznika w pętli. Jednak wszystko nadal kręci się wokół obiektów i ich metod.

Kod w typowo funkcyjnym stylu (Scala) może wyglądać jeszcze prościej:

val total: BigDecimal =
  orders
    .filterNot(_.cancelled)
    .map(_.amount)
    .sum

Zamiast zmiennego stanu jest tu opis przekształceń na kolekcji: przefiltruj, zamapuj, zsumuj. Program mówi, jaki rezultat ma powstać z danych wejściowych, a nie jak krok po kroku iterować po liście.

Typowe problemy klasycznego kodu: stan, debugowanie, efekty uboczne

Kod pisany w stylu imperatywnym i mocno obiektowym zwykle cierpi na kilka powtarzalnych problemów:

• Stan rozproszony – mnóstwo pól w klasach, singletony, konfiguracje globalne; trudno ustalić, co zmienia co.
• Trudne debugowanie – ten sam kod wywołany w innej kolejności daje inny rezultat, bo stan został już wcześniej „naruszony”.
• Magiczne efekty uboczne – metoda o pozornie niewinnej nazwie modyfikuje coś globalnego, zapisuje do bazy, wysyła maila itd.
• Mutacje w wielu miejscach – jedna lista jest przekazywana do kilku metod i każda z nich ją po trochu zmienia.

W praktyce oznacza to kod, który „działa, ale wszyscy boją się go dotykać”. Każda zmiana może naruszyć zależne fragmenty systemu, a im więcej współbieżności (wątki, asynchroniczność), tym bardziej ten problem narasta.

Jak programowanie funkcyjne łagodzi te problemy

Programowanie funkcyjne (FP) zwykle stawia trzy filary:

• funkcje czyste – bez ukrytych efektów ubocznych,
• niezmienność danych – brak modyfikowania struktur „w miejscu”,
• deklaratywne operacje na kolekcjach – mapy, filtry, redukcje zamiast pętli i liczników.

Konsekwencje są dość konkretne:

• funkcję łatwiej przetestować – dla tych samych danych wejściowych zawsze zwraca ten sam wynik,
• łatwiej przewidzieć skutki zmian – brak ukrytych modyfikacji stanu globalnego,
• współbieżność staje się mniej groźna – skoro dane są niezmienne, kilka wątków może z nich korzystać jednocześnie bez blokad.

Oczywiście FP nie jest magicznym lekiem na wszystkie problemy. Natomiast bardzo skutecznie ogranicza klasy błędów związanych z niekontrolowaną mutacją stanu i niejawnie rozlanymi efektami ubocznymi.

Mity do rozwiania: akademickość, wydajność, matematyka

Wokół FP narosło kilka mitów, które zwykle zniechęcają początkujących:

• „FP jest tylko akademickie” – Scala i Elixir są używane produkcyjnie w firmach tworzących systemy finansowe, systemy o bardzo dużej skali i platformy komunikacyjne. To nie są zabawki.
• „FP jest wolne” – wolne są niektóre naiwne konstrukcje, tak jak w każdym języku. Scala korzysta z JVM i bardzo dobrego JIT‑a, Elixir z maszyny BEAM zaprojektowanej do tysięcy lekkich procesów. W dobrze zaprojektowanych fragmentach kodu FP nie jest z zasady wolniejsze.
• „FP wymaga doktoratu z matematyki” – to mit szczególnie szkodliwy. Podstawowe techniki FP (czyste funkcje, niezmienność, map/filter) można opanować bez jakiejkolwiek zaawansowanej matematyki. Straszne słowa jak „funktor” czy „monada” można spokojnie odłożyć na później albo w ogóle ich nie używać, jeśli nie ma potrzeby.

W praktyce programowanie funkcyjne sprowadza się do innego, bardziej zdyscyplinowanego sposobu układania znanych już klocków – warunków, funkcji, kolekcji i przekształceń danych – a nie do pisania równań na tablicy.

Podstawowe idee programowania funkcyjnego – bez żargonu

Funkcje czyste: bez niespodzianek i ukrytych skutków

Funkcja czysta ma dwie kluczowe cechy:

1. Dla tych samych argumentów zawsze zwraca ten sam wynik.
2. Nie ma efektów ubocznych – nie zapisuje nic do bazy, nie loguje, nie modyfikuje parametrów ani stanu globalnego.

Przykład funkcji czystej (Scala):

def gross(net: BigDecimal, vatRate: BigDecimal): BigDecimal =
  net * (1 + vatRate)

Ta funkcja niczego nie zmienia na zewnątrz. Zawsze dla tych samych net i vatRate zwraca ten sam wynik. Można ją łatwo przetestować, a wynik obliczyć „w głowie”.

Dla kontrastu funkcja z efektami ubocznymi:

var lastGross: BigDecimal = 0

def grossWithSideEffect(net: BigDecimal, vatRate: BigDecimal): BigDecimal = {
  val g = net * (1 + vatRate)
  lastGross = g          // efekt uboczny: zmiana globalnego stanu
  println(s"Gross: $g")  // efekt uboczny: druk na konsolę
  g
}

Taka funkcja jest trudniejsza do analizy i testowania. Jeżeli logika czysta (obliczenie) jest wymieszana z efektami ubocznymi, każda zmiana wymaga większej ostrożności. W FP dąży się do oddzielenia części czystej od warstwy, która faktycznie „gada ze światem” (baza, pliki, HTTP).

Niezmienność danych (immutability) i jej konsekwencje

Niezmienność danych oznacza, że po utworzeniu struktury danych nie jest ona modyfikowana „w miejscu”. Zamiast tego tworzy się nową wersję na podstawie starej. W Scali typy tworzone przez case class są z założenia niezmienne (jeśli nie wprowadzi się pól zmiennych ręcznie). W Elixirze wszystkie standardowe struktury są niezmienne.

Przykład w Scali:

case class Order(id: String, amount: BigDecimal, cancelled: Boolean)

val o1 = Order("1", 100, cancelled = false)
// "zmiana" zamówienia tworzy nowy obiekt:
val o2 = o1.copy(cancelled = true)

Obiekt o1 pozostał nietknięty. To eliminuje cały wachlarz błędów typu „ktoś mi zmienił obiekt pod ręką”. Współdzielone dane nie psują się, bo po prostu nie są zmieniane.

W Elixirze każda „modyfikacja” mapy faktycznie zwraca nową mapę:

order = %{id: "1", amount: 100, cancelled: false}
updated = %{order | cancelled: true}

Pod spodem BEAM optymalizuje takie operacje, więc w praktyce nie oznacza to kopiowania wszystkiego od zera. Zazwyczaj struktury są współdzielone częściowo (struktury trwałe).

Deklaratywność zamiast ręcznego sterowania

W stylu imperatywnym programista mówi komputerowi: „zrób to, potem to, potem zwiększ licznik, sprawdź warunek, powtórz”. W stylu deklaratywnym opisuje raczej: „biorę te dane, filtruję według warunku, potem przeliczam, potem sumuję”.

Różnicę dobrze widać na pętlach. Imperatywna wersja:

var result = List[Int]()
for (i <- list) {
  if (i % 2 == 0) {
    result = result :+ (i * 2)
  }
}

Wersja funkcyjna w Scali:

val result: List[Int] =
  list
    .filter(_ % 2 == 0)
    .map(_ * 2)

Kod deklaratywny czyta się bardziej jak opis przetwarzania danych niż jak algorytm kontroli przepływu. W efekcie łatwiej zrozumieć, co robi program, bez śledzenia szczegółów wykonania krok po kroku.

Kompozycja funkcji i funkcje wyższego rzędu

Funkcja wyższego rzędu to po prostu funkcja, która przyjmuje inne funkcje jako argument albo zwraca funkcję. Nie ma w tym magii – to tylko konsekwencja traktowania funkcji jako zwykłych wartości.

Prosty przykład w Scali:

def applyDiscount(amount: BigDecimal, discount: BigDecimal => BigDecimal): BigDecimal =
  discount(amount)

val tenPercent: BigDecimal => BigDecimal =
  amount => amount * 0.9

val fixed20: BigDecimal => BigDecimal =
  amount => amount - 20

applyDiscount(100, tenPercent) // 90
applyDiscount(100, fixed20)    // 80

Ta sama funkcja applyDiscount może współpracować z różnymi strategiami rabatowania. Zamiast rozbudowywać hierarchię klas i wzorce typu Strategia, wykorzystuje się możliwość przekazywania zachowań wprost jako funkcji.

Kompozycja funkcji polega na łączeniu prostych funkcji w większe bloki. Jeśli jest funkcja f: A → B i g: B → C, to można je złożyć w funkcję h: A → C. W Scali:

val f: Int => Int = _ + 1
val g: Int => Int = _ * 2

val h: Int => Int = f.andThen(g) // najpierw f, potem g

h(3) // (3 + 1) * 2 = 8

Tak złożone funkcje zachowują przejrzystość: każda z osobna jest mała i łatwa do przetestowania, a razem tworzą bardziej złożone zachowanie.

Przykład „przed i po”: refaktoryzacja do stylu funkcyjnego

Załóżmy, że pojawia się funkcja, która ma:

• usunąć z listy użytkowników zablokowanych,
• zostawić tylko pełnoletnich,
• zwrócić listę ich nazw w wersji uppercase.

W stylu imperatywnym (Scala, ale w duchu Javy):

case class User(name: String, age: Int, blocked: Boolean)

def activeAdultNamesImperative(users: List[User]): List[String] = {
  var result = List[String]()
  for (u <- users) {
    if (!u.blocked && u.age >= 18) {
      result = result :+ u.name.toUpperCase
    }
  }
  result
}

Wersja funkcyjna:

def activeAdultNames(users: List[User]): List[String] =
  users
    .filter(u => !u.blocked && u.age >= 18)
    .map(_.name.toUpperCase)

Ta druga wersja jest krótsza, ale ważniejsze jest coś innego: nie ma tu żadnego mutowalnego stanu. Łatwo też dodać kolejne kroki przetwarzania, np. sortowanie lub usuwanie duplikatów, po prostu dokładamy kolejną operację na kolekcji.

Scala i Elixir – dwa różne światy FP, jeden cel

Scala: JVM, typy i łączenie OOP z FP

Scala jest językiem uruchamianym na JVM. Łączy paradygmat obiektowy i funkcyjny. W praktyce oznacza to, że:

• można korzystać z istniejących bibliotek javowych,
• można pisać w stylu mocno obiektowym, mocno funkcyjnym albo hybrydowym,
• dostępny jest rozbudowany system typów, case classes, pattern matching, funkcje jako „pierwszoplanowi obywatele”.

Scala szczególnie dobrze sprawdza się tam, gdzie:

• już istnieje infrastruktura JVM (Java, Kotlin),
• potrzebna jest wysoka wydajność i statyczne typowanie,
• tworzone są systemy przetwarzania danych, backendy HTTP, mikroserwisy, narzędzia infrastrukturalne.

Jeżeli w zespole dominuje Java lub Kotlin, Scala bywa naturalnym „kolejnym krokiem” – pozwala stopniowo wprowadzać podejście funkcyjne, nie rezygnując z dotychczasowego ekosystemu. Można zacząć bardzo zachowawczo: od prostych funkcji, niezmiennych case class i kilku operacji na kolekcjach, a dopiero później wchodzić w bardziej zaawansowane elementy systemu typów. Taki ewolucyjny tryb zwykle zmniejsza opór wobec zmiany stylu programowania.

W codziennej pracy z backendem HTTP typowy fragment logiki biznesowej może w Scali wyglądać jak jeden pipeline: walidacja danych wejściowych, pobranie czegoś z bazy, przetworzenie, przygotowanie odpowiedzi. Czyste fragmenty da się wydzielić do zwykłych funkcji, a warstwę „rozmowy ze światem” pozostawić w cienkiej otoczce (np. w kontrolerze). To co do zasady upraszcza testy: testuje się najpierw czysty moduł, a potem cienką integrację z infrastrukturą.

Scala dobrze nadaje się też do systemów przetwarzania strumieniowego (Spark, Akka Streams, FS2). Model funkcyjny – dane jako niezmienne strumienie, transformacje jako funkcje – naturalnie wpisuje się w zadania ETL, przetwarzanie eventów czy integracje pomiędzy systemami. Jeżeli w organizacji rośnie ilość danych do obróbki, przejście na takie narzędzia zwykle przychodzi szybciej, kiedy składnia języka nie odbiega drastycznie od dotychczasowych doświadczeń z JVM.

Nie można jednak pominąć kosztu nauki: składnia Scali, szczególnie w nowszych wersjach, jest elastyczna, ale bywa też gęsta. W praktyce pomaga przyjęcie jednego, rozsądnie prostego stylu w projekcie i trzymanie się go konsekwentnie zamiast wykorzystywania każdego możliwego udogodnienia języka.

Elixir i Scala pokazują tę samą ideę z różnych stron: funkcje jako podstawowe klocki, niezmienność danych i kompozycja zamiast rozbudowanych hierarchii obiektów. Niezależnie od tego, czy bliżej jest do JVM, czy do świata BEAM i współbieżności, wejście w programowanie funkcyjne zwykle zaczyna się tak samo – od małych, czystych funkcji i świadomego ograniczania stanu, krok po kroku przekładających się na bardziej przewidywalny i spokojniejszy w utrzymaniu kod.

Elixir: BEAM, współbieżność i prostota w praktyce

Elixir z kolei działa na maszynie wirtualnej Erlanga (BEAM). To środowisko od dekad projektowane pod kątem niezawodnych systemów telekomunikacyjnych, czyli takich, które mają działać bez przerwy, skalować się poziomo i radzić sobie z awariami pojedynczych komponentów bez wyłączania całości.

W praktyce oznacza to, że:

• podstawowym narzędziem są lekkie procesy BEAM, a nie wątki systemowe,
• komunikacja odbywa się przez wysyłanie wiadomości, nie przez współdzieloną pamięć,
• fail-fast jest normalnym wzorcem – proces nie „leczy się” sam, tylko w razie poważnego błędu po prostu umiera, a opiekun (supervisor) go odtwarza.

Styl funkcyjny w Elixirze jest bardziej „wymuszony” niż w Scali: brak mutowalnego stanu w strukturach danych, brak klasycznego OOP, wszystko kręci się wokół funkcji, modułów i procesów. Dla wielu programistów z tła obiektowego jest to subiektywnie większa zmiana, ale w zamian dostaje się prostszy, spójny model.

Elixir dobrze odnajduje się w kilku typowych obszarach:

• systemy komunikacyjne, czaty, powiadomienia w czasie rzeczywistym,
• backendy HTTP oparte o Phoenix – tam, gdzie ważna jest współbieżność i przewidywalne opóźnienia,
• przetwarzanie zdarzeń, integracje między systemami, kolejki, schedulery zadań.

Typowy serwer HTTP w Elixirze obsługuje każde żądanie w osobnym procesie BEAM. Logika biznesowa jest czystymi funkcjami, a proces jest jedynie „kontekstem wykonania”, który scala wejście/wyjście i przekazuje dane dalej. Takie odseparowanie ułatwia modernizację systemu: da się stopniowo wydzielać nowe procesy, zmieniać topologię nadzoru (supervision tree), nie naruszając czystych funkcji odpowiadających za reguły biznesowe.

Pierwsze kroki w Scali – składnia i sposób myślenia

Minimalny zestaw: wartości, funkcje, kolekcje

Na starcie wystarcza kilka elementów składni i jeden mentalny przeskok: wszystko, co się da, zapisywać jako wartości, a nie zmienne. Różnica między val a var nie jest wyłącznie stylistyczna.

// niemutowalna referencja
val x = 10

// mutowalna referencja
var y = 10
y = y + 1

W stylu funkcyjnym preferuje się val. Jeżeli coś musi wyglądać na „zmianę”, zwykle lepiej potraktować to jako utworzenie nowej wartości na podstawie starej:

val items = List(1, 2, 3)

// "dodanie" elementu
val extended = items :+ 4

// items pozostało niezmienione

Funkcje zapisuje się wprost jako wartości:

val double: Int => Int = x => x * 2

def applyTwice(f: Int => Int, x: Int): Int =
  f(f(x))

applyTwice(double, 3) // 12

Ten prosty przykład od razu pokazuje, dlaczego funkcje traktuje się jako dane: łatwo je przekazywać, komponować, testować oddzielnie.

Case classes i pattern matching – dane i ich kształt

W Scali duży ciężar przenosi się ze zhierarchizowanych klas na proste, niemutowalne „rekordy” i dopasowanie wzorców. Zamiast klasy z dziesiątkami metod, częściej używa się jednego lub kilku case class opisujących dane i osobnych funkcji działających na tych typach.

sealed trait PaymentStatus
case object Pending  extends PaymentStatus
case object Paid     extends PaymentStatus
case object Rejected extends PaymentStatus

case class Payment(id: String, amount: BigDecimal, status: PaymentStatus)

def isPayable(p: Payment): Boolean =
  p.status match {
    case Pending  => true
    case Paid     => false
    case Rejected => false
  }

sealed trait z zamkniętym zestawem implementacji oraz pattern matching tworzą coś w rodzaju bezpiecznego „enum + dane”. Kompilator podpowiada brakujące przypadki, co znacząco poprawia przewidywalność kodu, gdy system ewoluuje.

Funkcyjna obsługa błędów: Option i Either

Jednym z pierwszych usprawnień przy przechodzeniu na Scala-FP jest odejście od null i wyjątków jako głównego sposobu raportowania błędów. W zamian używa się typów takich jak Option i Either.

Option[A] oznacza „albo mam A, albo nie mam nic”. Zamiast ryzyka NullPointerException jest typ, który wymusza obsługę obu przypadków.

def findUser(id: String): Option[User] =
  // ... szukanie w bazie

val maybeUser: Option[User] = findUser("123")

val nameUpper: Option[String] =
  maybeUser.map(_.name.toUpperCase)

Podobnie Either[L, R] oznacza „albo lewa wartość (np. błąd), albo prawa wartość (np. wynik)”. W prostych projektach często wystarcza Either[String, A], gdzie String jest komunikatem błędu:

def parseAmount(raw: String): Either[String, BigDecimal] =
  try Right(BigDecimal(raw))
  catch { case _: NumberFormatException => Left("Invalid number") }

val result =
  parseAmount("10.5").map(_ * 2)

Zwracanie typu opisującego sukces lub błąd integruje się dobrze z operacjami na kolekcjach i kompozycją funkcji. Nie trzeba łapać wyjątków w losowych miejscach kodu – błędy przemieszczają się tym samym „kanałem” co zwykłe dane.

Pierwsze kroki w Elixirze – składnia, potoki i niezmienność

Funkcje i moduły – podstawowy budulec

Elixir stawia na moduły i funkcje. Nie ma klas ani dziedziczenia, więc segregacja kodu przebiega inaczej: moduł staje się jednostką organizacji odpowiedzialną za konkretny obszar.

defmodule Math do
  def double(x), do: x * 2

  def apply_twice(f, x), do: f.(f.(x))
end

Math.double(3)            # 6
Math.apply_twice(&Math.double/1, 3) # 12

Wywołanie funkcji przekazanej jako argument używa składni f.(x). Operator &Mod.func/arity tworzy „referencję do funkcji” – zwięzły sposób przekazania funkcji jako wartości.

Operator potokowy |> – czytelne przepływy danych

Elixir oferuje wygodny operator potokowy |>, który przekazuje wynik jednej funkcji jako pierwszy argument do następnej. Dla przetwarzania danych jest to bardzo czytelny zapis, zbliżony mentalnie do metody łańcuchowej w kolekcjach Scali, ale bardziej ogólny.

users
|> Enum.filter(&(&1.active))
|> Enum.map(&String.upcase(&1.name))

Powyższy fragment jest odpowiednikiem złożenia filter i map na liście. Zaletą potoków jest to, że można w nich mieszać funkcje z różnych modułów, nie ograniczając się do metod na kolekcjach:

order
|> validate_order()
|> enrich_with_customer()
|> calculate_totals()
|> persist()

Kolejne kroki są czytelnym opisem procesu. Każda z funkcji przyjmuje przetwarzany obiekt i zwraca jego kolejną wersję, co wpisuje się w model niezmienności.

Pattern matching i dopasowanie na głowie listy

Pattern matching w Elixirze jest wszechobecny – zarówno w dopasowaniu na krotkach, mapach, jak i na listach. Pozwala zapisać różne wersje tej samej funkcji jako osobne klauzule z warunkami na strukturze argumentu.

defmodule Sum do
  def list([]), do: 0

  def list([head | tail]) do
    head + list(tail)
  end
end

Sum.list([1, 2, 3]) # 6

Ta klasyczna rekursja pokazuje strukturę listy: [head | tail] oznacza element pierwszy i resztę listy. W produkcyjnym kodzie częściej używa się funkcji z modułu Enum zamiast ręcznej rekursji, ale świadomość tego mechanizmu ułatwia rozumienie wielu fragmentów kodu Elixira.

Dopasowanie działa także na mapach i strukturach (struct):

def handle(%{status: :pending} = order) do
  # logika dla pending
end

def handle(%{status: :paid} = order) do
  # logika dla paid
end

Zamiast rozbudowanych instrukcji if/case powstaje kilka jasno rozdzielonych wersji funkcji, każda dla innego kształtu danych.

Od pętli do operacji na kolekcjach – praktyczne przejście na FP

Ciągłe zwiększanie poziomu abstrakcji

Zmiana stylu kodu zwykle nie polega na jednym dużym refaktoringu, lecz na stopniowym podnoszeniu poziomu abstrakcji przy każdej kolejnej zmianie. Zamiast klasycznej pętli po liście łatwiej sięgnąć po map, filter i fold.

Przykład w Scali – sumowanie wartości z warunkiem:

// podejście imperatywne
var sum = BigDecimal(0)
for (o <- orders) {
  if (!o.cancelled) {
    sum = sum + o.amount
  }
}

// podejście funkcyjne
val sum2: BigDecimal =
  orders
    .filter(!_.cancelled)
    .map(_.amount)
    .sum

Druga wersja unika mutowalnej zmiennej sum i lepiej komunikuje zamiar. Ewentualna zmiana kryterium (np. dodatkowy warunek na typ zamówienia) sprowadza się do drobnej modyfikacji funkcji przekazywanej do filter.

Fold / reduce – ogólny wzorzec akumulacji

Zamiast ręcznego prowadzenia akumulatora w pętli, w podejściu funkcyjnym wykorzystuje się fold (Scala) lub Enum.reduce (Elixir). Pattern jest ten sam: jest jakiś stan początkowy i funkcja, która dla każdego elementu zwraca nowy stan.

Scala:

val totalAmount: BigDecimal =
  orders.foldLeft(BigDecimal(0)) { (acc, o) =>
    if (!o.cancelled) acc + o.amount else acc
  }

Elixir:

total_amount =
  Enum.reduce(orders, 0, fn order, acc ->
    if order.cancelled, do: acc, else: acc + order.amount
  end)

W obu przypadkach pętla i zarządzanie akumulatorem są „schowane” wewnątrz fold/reduce. Programista dostarcza jedynie funkcję opisującą, jak nowy element wpływa na stan.

Małe funkcyjne kroki w istniejącym projekcie

W projektach, które zaczynały w stylu czysto obiektowym, przejście na inne podejście zwykle przebiega etapami. W praktyce sprawdza się kilka prostych nawyków:

• zastępowanie pętli po kolekcjach lambda-wyrażeniami z map/filter/fold,
• wydzielanie małych czystych funkcji z długich metod,
• ograniczanie użycia var (Scala) lub mutowania struktur po stronie klienta (Elixir/Phoenix) na rzecz tworzenia nowych wartości.

Po kilku takich iteracjach duża część logiki zaczyna przypominać przetwarzanie strumieni danych, a nie ręczne sterowanie przepływem. To zwykle dobry moment na wprowadzenie bardziej zaawansowanych konstrukcji (np. monad pokroju Either czy własnych typów domenowych).

Praca ze stanem w świecie niezmienności

Rozdzielenie stanu lokalnego i współdzielonego

Nawet w projektach nastawionych na czysto funkcyjny styl nie da się całkowicie uniknąć stanu. Pojawia się w cache’ach, sesjach użytkownika, połączeniach z bazą, obsłudze kolejek. Kluczowe jest rozróżnienie stanu lokalnego (istotnego tylko w obrębie jednej funkcji lub jednego żądania) od stanu współdzielonego (widocznego dla wielu wywołań).

W podejściu funkcyjnym dąży się do tego, aby:

• stan lokalny przekazywać jawnie jako argument i wynik funkcji,
• stan współdzielony trzymać na „brzegach” systemu – w procesach BEAM, aktorach, serwisach infrastrukturalnych – a nie w dowolnych obiektach.

W Scali częścią odpowiedzi na ten problem jest model aktorów (np. Akka) albo konstruktów współbieżności w bibliotekach funkcyjnych (Cats Effect, ZIO). W Elixirze rolę tę pełnią procesy i genserwery.

Stan w Scali: aktor, serwis, efekt

W projektach korzystających ze Scali w duchu FP spotyka się co do zasady trzy podejścia do stanu:

1. stan kapsułkowany w serwisie (np. w Repository), ale manipulowany w sposób funkcyjny,
2. stan utrzymywany w aktorze, który sekwencyjnie przetwarza wiadomości,
3. stan opakowany w typ efektu, który kontroluje dostęp (np. Ref w Cats Effect).

Przykład z użyciem Ref (uproszczony, pomijający importy):

def program[F[_]: Concurrent]: F[Unit] =
  for {
    ref <- Ref.of[F, Int](0)              // stan: licznik
    _   <- ref.update(_ + 1)             // zmiana stanu
    v   <- ref.get                       // odczyt stanu
    _   <- Sync[F].delay(println(v))
  } yield ()

Licznik jest współdzielony, ale dostęp do niego odbywa się wyłącznie przez operacje dostarczane przez Ref. Każda modyfikacja zwraca nowy efekt opisujący zmianę, a biblioteka dba o bezpieczeństwo współbieżne. Kod wyraźnie rozdziela opis operacji (sekwencja kroków w for-comprehension) od ich faktycznego wykonania.

W serwisach HTTP opartych na Cats Effect lub ZIO podobny wzorzec pozwala utrzymywać w pamięci licznik metryk, cache czy prosty stan sesji. Różnica względem klasycznego singletona z polem var jest zasadnicza: stan nie jest widoczny „wszędzie”, lecz przekazywany do komponentów, które go potrzebują, zwykle jako zależność konstruktora.

Stan w Elixirze: procesy i GenServer

W Elixirze wspólny stan trzyma się zazwyczaj w procesach BEAM zarządzanych przez OTP. Typowy wzorzec to moduł oparty o GenServer, który kapsułkuje wewnętrzny stan i wystawia jasno określone API.

defmodule Counter do
  use GenServer

  # API
  def start_link(initial  0) do
    GenServer.start_link(__MODULE__, initial, name: __MODULE__)
  end

  def increment, do: GenServer.cast(__MODULE__, :inc)
  def get,       do: GenServer.call(__MODULE__, :get)

  # Callbacks
  @impl true
  def init(initial) do
    {:ok, initial}
  end

  @impl true
  def handle_cast(:inc, state) do
    {:noreply, state + 1}
  end

  @impl true
  def handle_call(:get, _from, state) do
    {:reply, state, state}
  end
end

Stan licznika istnieje tylko wewnątrz procesu, a modyfikacje odbywają się poprzez wysyłanie wiadomości. handle_cast i handle_call przyjmują poprzedni stan i zwracają jego nową wersję, nie modyfikując nic „w miejscu”. Proces przetwarza kolejne wiadomości sekwencyjnie, więc nie trzeba martwić się blokadami czy sekcjami krytycznymi.

W aplikacjach biznesowych taki proces może reprezentować koszyk użytkownika, bufor zdarzeń czy lokalny cache konfiguracji. Interakcja z nim pozostaje funkcyjna na poziomie pojedynczych wywołań (funkcje przyjmują dane i zwracają wynik), a jednocześnie otrzymujemy klarowny punkt, w którym stan jest utrzymywany i nad którym łatwo zapanować, np. restartując proces lub implementując strategię nadzorcy.

Scala i Elixir prowadzą więc do podobnego modelu myślenia: logika domenowa opisana jako zestaw czystych funkcji, a stan konsekwentnie odsunięty na krawędzie systemu i trzymany w dobrze zdefiniowanych prymitywach. Dzięki temu kolejne zmiany, testy i optymalizacje opierają się bardziej na przekształcaniu danych niż na śledzeniu wielu współdzielonych zmiennych, co w dłuższej perspektywie zwykle upraszcza pracę całemu zespołowi.

Łączenie świata funkcyjnego z imperatywnym i obiektowym

Granice modułów jako granice paradygmatów

W istniejących systemach Scala i Elixir bardzo rzadko występują w „czystej” postaci FP od pierwszej linijki. Częściej funkcyjne podejście wprowadza się stopniowo, zaczynając od nowych modułów, a dopiero później przebudowując starsze części. Dobrym, stosunkowo bezpiecznym miejscem na granicę paradygmatów jest granica modułów lub warstw.

W Scali da się utrzymać logikę domenową w postaci czystych funkcji i prostych typów danych, a na brzegu – np. w warstwie HTTP czy integracji z bazą – korzystać z bardziej imperatywnego kodu, współbieżności opartej o Future albo nawet z istniejących klas Javy. Przykładowy podział bywa następujący:

• warstwa domenowa: case classy, sealed trait-y, czyste funkcje,
• warstwa aplikacyjna: serwisy łączące wywołania funkcji domenowych,
• warstwa infrastruktury: adaptery do bazy, HTTP, kolejek – tu dopuszcza się bardziej „techniczny” imperatywny styl.

Elixir ze swoim podejściem „functional core, process shell” prowadzi w podobnym kierunku. Logika przekształcania danych jest zamknięta w modułach z czystymi funkcjami, a kontekst wykonania (proces, GenServer, Task) utrzymuje stan i odpowiada za komunikację. Granica między tymi światami bywa wtedy bardzo wyraźna: funkcje w rdzeniu nie wiedzą nic o procesach, a procesy obsługują wyłącznie wejście/wyjście i zarządzanie życiem komponentu.

Adaptowanie API obiektowego w Scali

W projektach korzystających z bibliotek javowych trudno uciec od obiektowego API. Zamiast próbować je przepisywać, częściej stosuje się wzorzec „funkcyjnego adaptera”. Kod mostkujący pozostaje cienką warstwą otaczającą istniejące wywołania, ale od strony reszty systemu wystawia już interfejs w stylu FP.

Przykład: istnieje biblioteka Javy, która zapisuje dokumenty do bazy w sposób blokujący:

class LegacyClient {
  public Document save(Document doc) throws IOException {
    // zapis do zewnętrznego systemu
  }
}

W Scali, w projekcie opartym na Cats Effect, można taki kod „opakować”:

final class LegacyClientWrapper[F[_]: Sync](underlying: LegacyClient) {

  def save(doc: Document): F[Document] =
    Sync[F].blocking {
      underlying.save(doc)
    }
}

Od strony reszty systemu operuje się na efektach F[Document], które można komponować, testować w izolacji (przy użyciu fałszywych implementacji) i wykonywać w kontrolowany sposób. Imperatywny świat zostaje zamknięty w niewielkiej liczbie adapterów, a nie „przecieka” po całym kodzie.

Świadome użycie efektów ubocznych w Elixirze

Elixir natury swojej nie ogranicza efektów ubocznych tak silnie jak biblioteki efektowe w Scali, ale dobrą praktyką jest płytkie umieszczanie IO w strukturze modułów. Często stosuje się prosty podział:

• moduły MyApp.Core.* – niemal wyłącznie czyste funkcje operujące na mapach, strukturach i listach,
• moduły MyApp.Boundary.* – interakcje z bazą, usługami zewnętrznymi, loggerem, systemem plików.

Kod w Core pozostaje łatwy do testowania, a w Boundary koncentruje się integracja z otoczeniem. Przyrostowo przenosząc logikę do Core, redukuje się ilość miejsc, w których jednocześnie odbywa się modyfikacja stanu i przekształcanie danych.

Praktyczne strategie testowania kodu funkcyjnego

Testowanie czystych funkcji: dane wejściowe, dane wyjściowe

Czyste funkcje sprzyjają bardzo bezpośredniemu stylowi testowania – bez mocków, stubów i skomplikowanych konfiguracji. Dla Scali i Elixira zasada jest podobna: dla danej kombinacji argumentów funkcja powinna zwrócić przewidywalny wynik.

Scala:

case class Order(amount: BigDecimal, cancelled: Boolean)

def totalAmount(orders: List[Order]): BigDecimal =
  orders
    .filterNot(_.cancelled)
    .map(_.amount)
    .sum

Test w ScaliTest lub MUnit może wyglądać po prostu tak:

test("totalAmount ignores cancelled orders") {
  val orders = List(
    Order(10, cancelled = false),
    Order(5,  cancelled = true),
    Order(7,  cancelled = false)
  )

  assertEquals(totalAmount(orders), BigDecimal(17))
}

Analogiczny test w Elixirze:

defmodule Billing do
  def total_amount(orders) do
    orders
    |> Enum.reject(& &1.cancelled)
    |> Enum.map(& &1.amount)
    |> Enum.sum()
  end
end

defmodule BillingTest do
  use ExUnit.Case

  test "total_amount ignores cancelled orders" do
    orders = [
      %{amount: 10, cancelled: false},
      %{amount: 5,  cancelled: true},
      %{amount: 7,  cancelled: false}
    ]

    assert Billing.total_amount(orders) == 17
  end
end

Bez wstrzykiwania zależności, bez konfigurowania zewnętrznych serwisów – wystarczy podać wejście i sprawdzić wynik. W codziennej pracy taki styl testowania ogranicza liczbę przypadków, w których niezbędne są cięższe narzędzia.

Testowanie efektów i stanu w Scali

Kiedy w grę wchodzi stan i efekty, w Scali przydają się abstrakcje typu F[_]. Umożliwiają one symulowanie świata zewnętrznego w testach, bez realnych wywołań IO. Zamiast IO można użyć np. cats.effect.IO z wbudowanym runtime lub specjalizowanych typów testowych (np. z ZIO Test).

Przykładowo, jeżeli logika aplikacyjna korzysta z repozytorium opisane­go interfejsem:

trait Orders[F[_]] {
  def find(id: OrderId): F[Option[Order]]
  def save(order: Order): F[Unit]
}

to w testach można przygotować prostą, w pełni funkcyjną implementację w pamięci:

final class InMemoryOrders[F[_]: Sync](
  ref: Ref[F, Map[OrderId, Order]]
) extends Orders[F] {

  def find(id: OrderId): F[Option[Order]] =
    ref.get.map(_.get(id))

  def save(order: Order): F[Unit] =
    ref.update(_.updated(order.id, order))
}

Testy logiki wyższego poziomu operują wtedy wyłącznie na tej implementacji, bez prawdziwej bazy. Stan pozostaje kontrolowany w Ref, a dzięki temu można go łatwo zainicjalizować i zweryfikować po wykonaniu scenariusza.

Testowanie procesów i GenServerów w Elixirze

Elixir ułatwia testowanie procesów dzięki temu, że procesy są lekkie i można je bez kosztu uruchamiać w testach. Również tutaj opłaca się wydzielić część czysto-funkcyjną od warstwy procesów.

Dobrym podejściem jest wydzielenie modułu odpowiedzialnego za obliczenia, np.:

defmodule Cart.Core do
  def add(cart, item) do
    %{cart | items: [item | cart.items]}
  end

  def total(cart) do
    cart.items
    |> Enum.map(& &1.price)
    |> Enum.sum()
  end
end

Następnie GenServer używa tego modułu:

defmodule Cart.Server do
  use GenServer
  alias Cart.Core

  def start_link(_opts) do
    GenServer.start_link(__MODULE__, %{items: []})
  end

  def add(pid, item), do: GenServer.cast(pid, {:add, item})
  def total(pid),     do: GenServer.call(pid, :total)

  @impl true
  def handle_cast({:add, item}, cart) do
    {:noreply, Core.add(cart, item)}
  end

  @impl true
  def handle_call(:total, _from, cart) do
    {:reply, Core.total(cart), cart}
  end
end

W testach logikę Cart.Core można weryfikować niezależnie, a Cart.Server testować jako cienką warstwę procesową:

test "cart server accumulates items" do
  {:ok, pid} = Cart.Server.start_link([])

  Cart.Server.add(pid, %{price: 10})
  Cart.Server.add(pid, %{price: 5})

  assert Cart.Server.total(pid) == 15
end

Taki podział sprawia, że ewentualne błędy związane z kolejnością wiadomości czy restartami procesów nie mieszają się z błędami samej logiki przetwarzania danych.

Modelowanie domeny za pomocą typów

Wymuszanie poprawności na poziomie kompilacji w Scali

Jednym z praktycznych atutów Scali w kontekście FP jest możliwość dość precyzyjnego modelowania domeny poprzez typy. Zamiast operować na gołych String czy Int, można zdefiniować niewielkie typy opakowujące, które ograniczają pole manewru już na etapie kompilacji.

Załóżmy potrzebę odwzorowania statusu zamówienia. Zamiast używać String lub Int z kodem statusu, można napisać:

sealed trait OrderStatus
object OrderStatus {
  case object Pending  extends OrderStatus
  case object Paid     extends OrderStatus
  case object Shipped  extends OrderStatus
  case object Cancelled extends OrderStatus
}

W efekcie funkcja przyjmująca OrderStatus nie przyjmie już błędnego ciągu znaków. Dalsze zawężanie można osiągnąć za pomocą zamkniętych hierarchii i dopasowania wzorców. Kompilator przypomni o nieobsłużonych przypadkach:

def nextActions(status: OrderStatus): List[String] =
  status match {
    case OrderStatus.Pending  => List("send_payment_reminder")
    case OrderStatus.Paid     => List("prepare_shipping")
    case OrderStatus.Shipped  => List("track_delivery")
    // brak Cancelled - ostrzeżenie od kompilatora (exhaustivity)
  }

W projektach o dłuższym cyklu życia takie modelowanie często redukuje liczbę błędów wynikających z nieobsłużonych stanów, bo kompilator zwyczajnie nie pozwala o nich zapomnieć.

Proste, ekspresyjne struktury w Elixirze

Elixir nie posiada statycznego systemu typów, ale umożliwia tworzenie przejrzystych struktur danych przy pomocy struktur (structs) i modułów. Zamiast przechowywać w mapie dowolne pola, można zdefiniować strukturę z domyślnymi wartościami i mechanizmami walidacji.

defmodule Order do
  @enforce_keys [:id, :amount]
  defstruct [:id, :amount, status: :pending]

  @type status :: :pending | :paid | :shipped | :cancelled
  @type t :: %__MODULE__{
          id: any(),
          amount: number(),
          status: status()
        }

  def mark_paid(%__MODULE__{status: :pending} = order) do
    %{order | status: :paid}
  end

  def mark_paid(%__MODULE__{} = order) do
    {:error, :invalid_status}
  end
end

Choć typy w dokumentacji są opcjonalne i weryfikowane głównie przez narzędzia (Dialyzer, IDE), dopasowanie wzorców i @enforce_keys wprowadzają minimalny, ale często wystarczający poziom ochrony. Korzystanie z Order.mark_paid/1 stanowi centralny punkt wprowadzania takiej zmiany, co ogranicza powstawanie rozbieganej logiki statusów w wielu miejscach kodu.

Sumy i produkty: te same idee, różna forma

Na poziomie idei Scala i Elixir pozwalają modelować domenę podobnie. W Scali sealed trait z case classami reprezentuje sumę typów (jedno z wielu możliwych kształtów), a pola w case classie – ich produkt (współwystępujące dane). W Elixirze rolę sum pełnią zwykle atomy w polu type/kind albo różne kształty map, a produktową stronę zapewniają pola struktur.

Przykładowe modelowanie płatności w Scali:

sealed trait Payment
object Payment {
  final case class Card(number: String, cvc: String) extends Payment
  final case class Blik(phone: String)               extends Payment
  final case class Transfer(iban: String)            extends Payment
}

Odpowiadająca koncepcja w Elixirze:

defmodule Payment do
  @type t ::
          {:card, %{number: String.t(), cvc: String.t()}}
          | {:blik, %{phone: String.t()}}
          | {:transfer, %{iban: String.t()}}

  def mask({:card, data}), do: {:card, %{data | number: "****"}}
  def mask({:blik, data}), do: {:blik, data}
  def mask({:transfer, data}), do: {:transfer, data}
end

Choć narzędzia językowe są inne, sposób myślenia pozostaje zbliżony: kod ma jasno określone KTO i CO może wystąpić w danym miejscu, a obsługa tych przypadków jest wyraźnie wydzielona i kompletna.

Stopniowe wprowadzanie Scali i Elixira w zespole

Małe, zamknięte w sobie eksperymenty

Przy zmianie paradygmatu na bardziej funkcyjny najrozsądniej zacząć od niewielkich, jasno ograniczonych zadań. Przykładem może być osobny moduł odpowiedzialny za kalkulacje podatkowe, generowanie raportu czy czyszczenie danych importowanych z zewnętrznego systemu. W takich miejscach łatwiej przyjąć założenie, że moduł będzie napisany „niemal czysto funkcyjnie” i zbudować go niejako obok reszty systemu.

W praktyce oznacza to często, że:

• moduł ma dobrze zdefiniowane wejście (np. kolekcja struktur) i wyjście,
• logika nie dotyka bezpośrednio bazy, sieci, czasu ani plików,
• całość da się przetestować kilkoma lub kilkunastoma testami jednostkowymi.

Takie małe „wyspy” w kodzie bywają dobrym miejscem na pierwsze zetknięcie zespołu z niezmiennością, funkcjami wyższego rzędu czy dopasowaniem wzorców. Łatwiej wtedy przećwiczyć nowe nawyki – choćby to, żeby nie modyfikować obiektu przekazanego w argumencie, tylko zwracać jego nową wersję. Gdy taki moduł przyjmie się w produkcji i przetrwa pierwsze zmiany wymagań, zespołowi zwykle rośnie zaufanie do nowego stylu i chętniej przenosi go na kolejne fragmenty systemu.

W Scali naturalnym kandydatem na takie eksperymenty są moduły/osobne biblioteki, które wystawiają jedno lub kilka czystych API, np. funkcję calculateTaxes(order: Order): TaxSummary. Moduł można podpiąć do istniejącej aplikacji JVM, nawet jeśli reszta kodu jest pisana w stylu obiektowym. W Elixirze analogiczną rolę często pełnią konteksty (np. MyApp.Billing), w których da się wyraźnie rozdzielić czysto-funkcyjne podmoduły (Billing.Core) od warstwy repozytoriów i procesów (Billing.Worker, Billing.Repo).

Dodatkowym ułatwieniem jest podejście „feature flag”: nowe, funkcyjne moduły wdraża się równolegle do starej implementacji i przez pewien czas uruchamia tylko dla części ruchu albo tylko w środowisku testowym. Pozwala to bezpiecznie sprawdzić, czy inne komponenty systemu poprawnie współpracują z nowym stylem kodu, bez konieczności natychmiastowego usuwania istniejących rozwiązań.

Kolejny krok to przenoszenie podejścia FP na te fragmenty systemu, gdzie dziś utrzymanie sprawia najwięcej problemów: złożone raporty, przetwarzanie wsadowe, nietrywialne reguły biznesowe. Zwykle tam korzyści z czytelniejszego przepływu danych, braku efektów ubocznych i lepszej testowalności są najbardziej odczuwalne. Nie ma konieczności „przepisywania świata”; sensowniejsze jest wymienianie elementów układanki tam, gdzie koszt zmiany jest rozsądny, a zysk z przewidywalności kodu – wyraźny.

Scala i Elixir pokazują, że programowanie funkcyjne nie musi być ani hermetyczną teorią, ani rewolucją robioną jednego dnia. Stopniowe wprowadzanie prostych, czystych funkcji, jawnego modelowania domeny oraz świadomego zarządzania stanem pozwala krok po kroku porządkować istniejące systemy i spokojnie budować nowe, bardziej przewidywalne aplikacje.

Łączenie paradygmatów: funkcyjnie tam, gdzie to ma sens

Przy pracy ze Scalą i Elixirem trudno całkowicie uciec od paradygmatu obiektowego czy imperatywnego. Zwykle nie ma też takiej potrzeby. Zamiast radykalnego odcięcia składników, rozsądniej jest wybrać miejsca, w których styl funkcyjny przynosi wyraźne korzyści, a w innych częściach kodu pozostać przy rozwiązaniach prostszych lub po prostu już działających.

W Scali dość naturalny jest podział na:

• warstwę „na brzegu” systemu – kontrolery HTTP, integracje z bazą, adaptory do systemów zewnętrznych, które zwykle korzystają z efektów ubocznych, mutowalnych buforów czy API frameworka,
• rdzeń domenowy – zbiory funkcji i klas, w których operacje na danych są w miarę czyste, a stan jest reprezentowany przez niezmienne struktury i przekazywany jawnie.

Kod „brzegowy” może wyglądać dość obiektowo:

class OrdersController(service: OrdersService) {
  def pay(orderId: String): HttpResponse = {
    service
      .pay(orderId)
      .fold(
        error => HttpResponse.badRequest(error.message),
        _     => HttpResponse.ok()
      )
  }
}

Pod spodem funkcja serwisowa może być już znacznie bardziej funkcyjna:

class OrdersService(repo: OrdersRepo, payments: PaymentsGateway) {

  def pay(orderId: String): Either[PaymentError, Receipt] =
    for {
      order   <- repo.find(orderId).toRight(OrderNotFound(orderId))
      _       <- ensurePayable(order)
      receipt <- payments.charge(order.total)
      _        = repo.save(order.markPaid()) // efekt uboczny wydzielony
    } yield receipt

  private def ensurePayable(order: Order): Either[PaymentError, Unit] =
    order.status match {
      case OrderStatus.Pending => Right(())
      case _                   => Left(AlreadyPaidOrCancelled(order.id))
    }
}

Efekt uboczny (zapis do repozytorium) jest jawnie oznaczony, a logika decyzyjna działa na niezmiennych strukturach i typach domenowych. Można z nią pracować, testować ją i refaktoryzować w podobny sposób jak z czystymi funkcjami, mimo że cała metoda formalnie pozostaje „imperatywna”.

W Elixirze podobną rolę pełni zwykle cienka otoczka wokół modułów korzystających z Ecto, GenServerów czy bibliotek do HTTP. Kod domenowy bywa osobnym modułem o prostych zależnościach:

defmodule Billing.Payments do
  alias Billing.{Order, Receipt}

  @spec pay(Order.t()) :: {:ok, Receipt.t()} | {:error, term()}
  def pay(%Order{status: :pending} = order) do
    with {:ok, receipt} <- charge(order),
         updated_order   = %{order | status: :paid}
    do
      {:ok, updated_order, receipt}
    end
  end

  def pay(%Order{}), do: {:error, :invalid_status}

  defp charge(order) do
    # tu można wstrzyknąć adapter, mockować w testach itd.
  end
end

GenServer może korzystać z takiego modułu jako z „silnika” logiki, samemu zajmując się wyłącznie kolejkowaniem wywołań i odpornością na awarie. Taki rozdział ułatwia zachowanie zdrowej proporcji: tam, gdzie logika ma być przejrzysta i testowalna – styl funkcyjny, tam, gdzie interakcja ze światem zewnętrznym jest gęsta – praktyczny, często bardziej bezpośredni kod.

Funkcyjne nawyki w istniejącej bazie kodu

Minimalne zmiany, które dają zauważalny efekt

W wielu projektach nie da się ani nie opłaca się wykonać „twardego zwrotu” w stronę FP. Można jednak stopniowo wprowadzać drobne nawyki, które istotnie poprawiają czytelność i przewidywalność kodu, nawet jeśli reszta architektury pozostaje taka jak dotychczas.

W Scali sensowne pierwsze kroki to:

• preferowanie val zamiast var,
• unikanie metod, które w ukryciu modyfikują stan obiektu – zamiast nich metody zwracające nową instancję,
• częstsze korzystanie z kolekcji niezmiennych (List, Vector) i funkcji takich jak map, fold, filter zamiast pętli modyfikujących zewnętrzne zmienne.

Zamiast:

var total = 0
for (item <- items) {
  total += item.price
}

można stopniowo przechodzić na:

val total = items.map(_.price).sum

Niewielka zmiana, a znika mutacja i możliwość, że zmienna total zostanie zaktualizowana w wielu miejscach naraz. Analogicznie w Elixirze pętle for z akumulacją w zewnętrznej zmiennej ustępują miejsca funkcjom z modułu Enum lub Stream:

total = Enum.reduce(items, 0, fn item, acc -> acc + item.price end)

Tego typu modyfikacje są zatrzymaniem dryfowania w stronę kodu „zaskakującego”, w którym zmienne zmieniają znaczenie w trakcie funkcji. Nie trzeba wprowadzać od razu monad czy złożonych bibliotek – wystarcza decyzja, że stan będzie lokalny, jawnie przekazywany i nie będzie modyfikowany „przy okazji”.

Wyciąganie logiki z metod i callbacków

W projektach, które korzystają intensywnie z frameworków (web, GUI, integracje), wiele decyzji biznesowych trafia do callbacków, handlerów albo metod kontrolerów – często razem z obsługą błędów, logowaniem i mapowaniem danych. Fragmenty, które faktycznie stanowią logikę domenową, można zwykle bezbolesnie wyciąć do osobnych funkcji lub modułów.

Przykład w Scali – metoda kontrolera może zawierać logikę i efekty uboczne wymieszane ze sobą:

def placeOrder(request: HttpRequest): HttpResponse = {
  val userId = request.headers.get("X-User-Id").get
  val cart   = loadCart(userId)
  if (cart.items.isEmpty) {
    HttpResponse.badRequest("empty cart")
  } else {
    val total = cart.items.map(_.price).sum
    if (total > 10000) {
      HttpResponse.badRequest("limit exceeded")
    } else {
      val order = createOrder(userId, cart.items, total)
      saveOrder(order)
      clearCart(userId)
      HttpResponse.ok(order.id)
    }
  }
}

Po drobnej refaktoryzacji kluczowe decyzje mogą trafić do czystej funkcji:

final case class Cart(items: List[CartItem])
final case class OrderRequest(userId: String, cart: Cart)
final case class OrderDecision(result: Either[String, Order])

def decideOrder(input: OrderRequest): OrderDecision = {
  import input._
  if (cart.items.isEmpty)
    OrderDecision(Left("empty cart"))
  else {
    val total = cart.items.map(_.price).sum
    if (total > 10000)
      OrderDecision(Left("limit exceeded"))
    else
      OrderDecision(Right(Order(userId, cart.items, total)))
  }
}

Kod kontrolera staje się prostą „otoczką”:

def placeOrder(request: HttpRequest): HttpResponse = {
  val userId = request.headers("X-User-Id")
  val cart   = loadCart(userId)

  decideOrder(OrderRequest(userId, cart)).result match {
    case Left(msg)  => HttpResponse.badRequest(msg)
    case Right(o)   =>
      saveOrder(o)
      clearCart(userId)
      HttpResponse.ok(o.id)
  }
}

W Elixirze podobne podejście sprawdza się w kontrolerach Phoenix czy callbackach Ecto. Funkcje w kontrolerze mogą być cienkimi adapterami, a zasadnicza logika – w osobnym, czystym module, który przyjmuje struktury i zwraca ich nowe wersje albo opakowane wyniki ({:ok, result} / {:error, reason}).

Unikanie typowych pułapek przy przechodzeniu na FP

„Funkcyjne” nazwy przy imperatywnym rdzeniu

Jednym z częstszych zjawisk jest przyjmowanie „funkcyjnego słownictwa”, bez faktycznej zmiany sposobu pracy ze stanem. Moduły nazywają się Core, funkcje mapSomething, ale pod spodem wciąż dominuje mutacja współdzielonego stanu, globalne singletons i ukryte efekty uboczne.

W Scali objawia się to czasami przez intensywne użycie kolekcji niezmiennych i wywołań map/flatMap, które jednak wewnątrz funkcji wołają np. o zapis do bazy czy zewnętrznego systemu:

orders.map { order =>
  val updated = order.copy(status = Paid)
  repo.save(updated)         // efekt uboczny w map
  notifyExternal(updated)    // kolejny efekt uboczny
  updated
}

Takie konstrukcje bywają mylące – wyglądają na proste przekształcenie kolekcji, ale faktycznie wykonują serię operacji IO. Rozsądniej jest jawnie wydzielić część czysto funkcyjną (przekształcenie) i część efektową (zapis, powiadomienie), np. poprzez:

• osobną funkcję tworzącą nowy stan,
• osobny krok stosujący skutki uboczne do uzyskanej kolekcji.

W Elixirze podobny problem pojawia się, gdy w funkcjach mających być „rdzeniem logiki” pojawiają się bezpośrednie wywołania na Repo, zewnętrznych klientach HTTP czy GenServerach. Bywa to nieuniknione, ale tam, gdzie logika zaczyna się gmatwać, wydzielenie czystych funkcji radykalnie ułatwia testowanie i myślenie o konsekwencjach zmian.

Przeginka z generowaniem abstrakcji

Drugą skrajnością jest przesadne komplikowanie kodu w imię „czystości funkcyjnej”. W Scali łatwo popaść w nadmierne użycie zaawansowanych konstrukcji typów, własnych monad czy wielowarstwowych transformacji, które potem rozumieją dwie osoby w zespole. W Elixirze zdarzają się z kolei moduły rozdrobnione do tego stopnia, że prosta ścieżka biznesowa wymaga prześledzenia kilkunastu połączeń funkcji.

Przy wyborze abstrakcji rozsądnie jest zadać kilka prostych pytań:

• czy nowa abstrakcja rozwiązuje problem występujący w wielu miejscach, czy tylko lokalną niewygodę,
• czy osoba dołączająca do projektu za pół roku będzie w stanie ją zrozumieć po lekturze kilku przykładów,
• czy testy jednostkowe dla tej abstrakcji są proste i opisują jej zachowanie wystarczająco jasno.

Jeżeli odpowiedź jest negatywna, często lepszy będzie prostszy, nawet lekko powtarzalny kod niż imponujący, ale mało przejrzysty system klas i typów.

Praktyczne wzorce organizacji kodu domenowego

„Anemiczna” domena z bogatymi funkcjami

Zarówno Scala, jak i Elixir dobrze znoszą styl, w którym struktury danych pozostają relatywnie proste, a główna logika jest skupiona w funkcjach lub metodach serwisów. Z punktu widzenia klasycznej, obiektowej szkoły może to przypominać „anemiczny model domenowy”, ale w kontekście FP bywa to sensowny kompromis.

W Scali struktura reprezentująca domenę może być zwykłą case class:

final case class Invoice(
  id: InvoiceId,
  items: List[InvoiceItem],
  status: InvoiceStatus
)

Podstawowe operacje na fakturze można jednak trzymać w osobnym obiekcie:

object InvoiceLogic {

  def addItem(invoice: Invoice, item: InvoiceItem): Invoice =
    invoice.copy(items = invoice.items :+ item)

  def total(invoice: Invoice): BigDecimal =
    invoice.items.map(_.amount).sum

  def canBeCancelled(invoice: Invoice): Boolean =
    invoice.status match {
      case Draft | Sent => true
      case Paid         => false
    }
}

Testy tego modułu są krótkie i klarowne, a sam model domenowy pozostaje prosty, bez złożonych hierarchii i kombinacji dziedziczenia. W Elixirze bardzo podobny efekt daje połączenie struktur z modułami „operacyjnymi”:

defmodule Invoice do
  @enforce_keys [:id, :items, :status]
  defstruct [:id, items: [], status: :draft]

  @type status :: :draft | :sent | :paid
  @type t :: %__MODULE__{
          id: any(),
          items: list(),
          status: status()
        }
end

defmodule InvoiceLogic do
  alias __MODULE__.Invoice

  @spec add_item(Invoice.t(), map()) :: Invoice.t()
  def add_item(%Invoice{} = invoice, item) do
    %{invoice | items: invoice.items ++ [item]}
  end

  @spec total(Invoice.t()) :: number()
  def total(%Invoice{items: items}) do
    Enum.reduce(items, 0, fn i, acc -> acc + i.amount end)
  end
end

Struktura przechowuje dane, moduł dostarcza operacji. Zmiana implementacji funkcji (np. sposobu liczenia podatku) nie wymaga dotykania sposobu przechowywania danych, a testy mogą być skupione wyłącznie na zachowaniu funkcji.

Warstwy: od czystego rdzenia do efektów ubocznych

Dobrym uzupełnieniem takiego podejścia jest warstwowe układanie modułów. Na jednym końcu znajdują się czyste funkcje domenowe, na drugim – warstwa IO, a pośrodku – cienkie adaptery.

Przykładowy podział w Scali:

• domain – modele, proste typy, logika obliczeniowa i walidacyjna, bez zależności od frameworków,
• application – serwisy orkiestrujące kilka operacji domenowych, korzystające z portów (interfejsów) repozytoriów, gatewayów itp.,
• infrastructure – implementacje portów, konkretne adaptery do baz, HTTP, kolejek, narzędzi chmurowych.

W Elixirze analogiczny schemat może wyglądać następująco:

• MyApp.Core.* – czyste moduły biznesowe,

• MyApp.Core.* – czyste moduły biznesowe,
• MyApp.App.* – kontekst aplikacyjny, który składa operacje domenowe w konkretne przypadki użycia,
• MyApp.Adapters.* – warstwa integracji z zewnętrznym światem: Repo, klienci HTTP, kolejki, systemy plików,
• MyAppWeb.* – kontrolery, view, kanały, które tłumaczą HTTP/WebSocket na wywołania App/Core.

W praktyce dobrze działa prosty nawyk: nową funkcję zaczyna się od umieszczenia jej w możliwie najniższej warstwie, w której da się ją zrealizować bez efektów ubocznych. Jeżeli dany fragment można zapisać bezpośrednio w Core, zwykle będzie dzięki temu bardziej zrozumiały i łatwiejszy w testowaniu. Dopiero gdy faktycznie trzeba sięgnąć po bazę, HTTP czy system plików, przechodzi się do wyższych warstw i dodaje adapter, który „opakuje” czyste wywołania w niezbędne IO.

Dobrze zorganizowana separacja warstw przekłada się także na łatwiejsze zmiany technologiczne. Zmiana biblioteki HTTP, migracja z jednego ORM-a na inny albo wydzielenie mikroserwisu często ograniczają się wtedy do warstwy adapterów. Scala i Elixir sprzyjają takiej architekturze: w Scali pomagają interfejsy (traits) oraz typy opisujące efekty, a w Elixirze – wyraźny podział aplikacji w umbrella projectach, konteksty oraz kontrakty zdefiniowane jako zachowania (@behaviour).

Podczas codziennej pracy przejście na myślenie „od funkcji i danych do efektów ubocznych” wymaga pewnej cierpliwości. Zwykle wygodniej jest wprowadzać je stopniowo: najpierw zamknąć pojedynczą ścieżkę biznesową w czystym module, później wyczyścić kolejną, zamiast przebudowywać całość naraz. Zarówno w Scali, jak i w Elixirze nawet częściowe zastosowanie opisanych wzorców daje zauważalny efekt – mniejszy chaos w kodzie, mniej zaskoczeń przy zmianach i testy, które faktycznie opisują logikę, a nie jedynie konfigurację frameworka.

Najczęściej zadawane pytania (FAQ)

Na czym polega różnica między programowaniem imperatywnym, obiektowym a funkcyjnym?

Programowanie imperatywne koncentruje się na krokach: mówisz komputerowi, co ma zrobić po kolei, często modyfikując zmienne (stan) w wielu miejscach. Typowy przykład to pętla z licznikiem i instrukcjami if w środku.

W podejściu obiektowym główną rolę odgrywają obiekty i ich metody. Logika jest „opakowana” w klasy, a stan bywa rozproszony po wielu instancjach i singletonach. Styl może być mniej lub bardziej zbliżony do funkcyjnego (np. strumienie w Javie).

Styl funkcyjny opisuje raczej, jak przekształcić dane wejściowe w wynik: filtruj, mapuj, redukuj. Zamiast zmieniać zmienne w pętlach, buduje się potoki operacji na kolekcjach. Kluczowe jest ograniczanie stanu, efektów ubocznych i mutacji.

Dlaczego programowanie funkcyjne uznaje się za „bezpieczniejsze” przy współbieżności?

W programowaniu funkcyjnym dane co do zasady są niezmienne: po utworzeniu struktury nie zmieniasz jej w miejscu, tylko tworzysz nową wersję. Jeżeli kilka wątków korzysta z tych samych danych, nie mogą ich sobie „popsuć”, bo nikt ich nie modyfikuje.

Do tego dochodzą funkcje czyste – ta sama funkcja dla tych samych argumentów zawsze zwraca ten sam wynik i nie grzebie w stanie globalnym. W efekcie łatwiej przewidzieć zachowanie systemu, bo mniej zależy od kolejności wywołań i aktualnego „humoru” współdzielonego stanu.

W praktyce oznacza to mniej klas błędów typu race condition, mniej konieczności stosowania blokad i mniej sytuacji, w których drobna zmiana kolejności wywołań psuje cały proces.

Czy programowanie funkcyjne jest wolniejsze od obiektowego?

Sam styl funkcyjny nie czyni kodu z definicji wolniejszym. Wydajność zależy raczej od konkretnej implementacji i narzędzi, z których się korzysta. Scala działa na JVM z zaawansowanym kompilatorem JIT, a Elixir na maszynie BEAM zaprojektowanej pod tysiące lekkich procesów.

Wolne bywają naiwne konstrukcje – np. bezrefleksyjne tworzenie milionów krótkich obiektów czy niepotrzebne kopiowanie kolekcji. Jednak w dojrzałych bibliotekach funkcyjnych stosuje się struktury trwałe, które współdzielą elementy pod spodem, więc koszt „modyfikacji” bywa zaskakująco niski.

W praktyce różnice wydajnościowe pomiędzy rozsądnie napisanym kodem obiektowym i funkcyjnym są często pomijalne wobec kosztów bazy danych, sieci czy IO.

Czy do programowania funkcyjnego w Scali lub Elixirze potrzebna jest zaawansowana matematyka?

Nie. Podstawowy poziom programowania funkcyjnego opiera się na pojęciach, które większość programistów zna intuicyjnie: funkcje, parametry, listy, filtrowanie, mapowanie, sumowanie. Można skutecznie pracować, znając wyłącznie te elementy.

Zaawansowany żargon (jak funktor czy monada) opisuje bardziej złożone abstrakcje, które przydają się w dużych systemach, ale nie są obowiązkowe na starcie. W wielu firmowych projektach korzysta się z prostych zasad: czyste funkcje, niezmienność, jasne oddzielenie logiki od efektów ubocznych.

Dopiero gdy ktoś chce wejść w bardzo formalne biblioteki lub pisać własne frameworki, zaawansowana teoria okazuje się realnie pomocna.

Jak w praktyce wygląda niezmienność danych w Scali i Elixirze?

W Scali często używa się case class, które z założenia są niezmienne. „Zmiana” obiektu polega na utworzeniu nowej instancji metodą copy. Współdzielone struktury pozostają nietknięte, a każda wersja obiektu jest dobrze określona w czasie.

W Elixirze wszystkie podstawowe struktury (listy, mapy, krotki) są niezmienne. Zapis %{mapa | klucz: nowa_wartosc} tworzy nową mapę opartą na starej. Pod spodem BEAM współdzieli części struktur, więc nie wiąże się to zwykle z pełnym kopiowaniem.

Przykładowo w systemie zamówień można bez obaw przekazywać te same obiekty do kilku funkcji – żadna z nich nie „po cichu” nie zmodyfikuje danych, na których opierają się inne fragmenty logiki.

Czym jest funkcja czysta i dlaczego tak mocno się ją podkreśla?

Funkcja czysta to taka, która dla tych samych argumentów zawsze zwraca ten sam wynik i nie wprowadza efektów ubocznych. Nie zapisuje nic do bazy, nie wysyła maili, nie modyfikuje zmiennych globalnych ani parametrów wejściowych.

Taka funkcja jest bardzo prosta do przetestowania i przeanalizowania – wystarczy sprawdzić argumenty, nie trzeba śledzić całego stanu aplikacji. W praktyce zmniejsza to ryzyko błędów, bo zmiana implementacji funkcji nie wpływa „po cichu” na inne fragmenty systemu.

Efekty uboczne w FP zwykle są izolowane: logika biznesowa pozostaje czysta, a operacje na świecie zewnętrznym (baza, pliki, HTTP) są skupione w ograniczonych miejscach kodu.

Czy warto zaczynać naukę programowania funkcyjnego od Scali czy Elixira?

Scala i Elixir nadają się do nauki FP, ale adresują nieco inne potrzeby. Scala łączy świat obiektowy i funkcyjny na JVM, więc bywa naturalnym krokiem dla osób po Javie czy Kotlinie. Pozwala stopniowo przesuwać się w stronę podejścia funkcyjnego, nie rezygnując z istniejącego ekosystemu.

Elixir stawia mocny nacisk na współbieżność, odporność na błędy i prostą składnię. Zwykle jest wybierany do systemów o dużej liczbie równoległych zadań (komunikatory, systemy eventowe), a jednocześnie wymusza funkcyjny styl, bo nie oferuje klasycznej mutowalności.

Wybór warto uzależnić od kontekstu: jeśli pracujesz w środowisku JVM, Scala będzie bardziej naturalna; jeśli interesują Cię systemy wysoko współbieżne i model aktorów BEAM, Elixir może być lepszym punktem wyjścia.

Kluczowe Wnioski

• Programowanie funkcyjne przesuwa akcent z opisu „jak krok po kroku coś zrobić” na opis „co ma zostać policzone”, dzięki czemu kod jest krótszy, bardziej opisowy i łatwiejszy do prześledzenia.
• Największe problemy klasycznego, imperatywnego i mocno obiektowego stylu to rozproszony stan, trudne debugowanie, ukryte efekty uboczne i mutacje danych w wielu miejscach – szczególnie bolesne w systemach współbieżnych.
• Trzy filary FP – funkcje czyste, niezmienność danych oraz deklaratywne operacje na kolekcjach (map, filter, reduce) – znacząco ograniczają klasę błędów wynikających z niekontrolowanych zmian stanu.
• Funkcje czyste, które dla tych samych argumentów zawsze zwracają ten sam wynik i nie modyfikują otoczenia, są dużo prostsze do testowania, rozumienia i ponownego użycia niż funkcje z efektami ubocznymi.
• Scala i Elixir są językami produkcyjnymi, wykorzystywanymi m.in. w systemach finansowych czy komunikacyjnych; nie są „akademickimi zabawkami” i zwykle nie przegrywają wydajnością, jeśli kod jest rozsądnie zaprojektowany.
• Podstawy FP – czyste funkcje, niezmienne struktury danych, praca na kolekcjach zamiast ręcznych pętli – nie wymagają zaawansowanej matematyki; bardziej przypominają zdyscyplinowane układanie dobrze znanych klocków.
• W praktyce przejście do stylu funkcyjnego oznacza mniejszy strach przed zmianami w kodzie: skutki modyfikacji są bardziej lokalne, a współdzielenie danych między wątkami czy procesami staje się bezpieczniejsze i mniej zaskakujące.

Bibliografia i źródła

• Functional Programming. Stanford Encyclopedia of Philosophy (2021) – Omówienie paradygmatu funkcyjnego, czyste funkcje, brak efektów ubocznych
• Functional Programming in Scala, 2nd Edition. Manning Publications (2023) – Wprowadzenie do FP w Scali: niezmienność, czyste funkcje, operacje na kolekcjach
• Programming Elixir ≥ 1.6. Pragmatic Bookshelf (2019) – Praktyczne wprowadzenie do Elixira, niezmienność danych, procesy na BEAM
• Scala Language Specification, Version 3. EPFL (2024) – Specyfikacja Scali: funkcje, kolekcje, case class, semantyka niezmienności
• Elixir Getting Started Guide. Elixir Core Team – Oficjalne wprowadzenie: niezmienność struktur, procesy, podstawy FP w Elixirze