Přejít k navigační liště

Zdroják » Databáze » Jak může funkcionální přístup obohatit OOP programátory

Jak může funkcionální přístup obohatit OOP programátory

Články Databáze

Krátký, ale důležitý přehled, který by vám něměl uniknout, ať již jste začátečník anebo pokročilý.

Text vyšel původně na webu autora.

Na jOpenSpace 2023 jsem se seznámil s Romanem Provazníkem. (Určitě si pusťte jeho přednášku Podcast DIY (téměř) zadarmo). Když jsem se dozvěděl, že ho pozvali kluci na Google Developers Group Jihlava, tak jsem tam s radostí vyrazil. Mluvil o tom, jak může funkcionální přístup obohatit OOP programátory. Ne, nebojte, F# propagovat nebudu, ale jako Java programátor jsem si udělal pár poznámek.

Side Effect

Nesnáším side effecty (s českým výrazem vedlejší účinek jsem se nesžil). Tady jsem si potvrdil své přesvědčení a navíc i inspiraci, jak kód lépe organizovat.

Ve funkcionálním světe tomu říkají pure/inpure. Nebo můžete znát návrhový vzor CQRS (Command and Query Responsibility Segregation). Prostě pojďme víc dbát na oddělení read/write operací.

Naposledy jsem se nějakou chvíli zasekl na metodě findPendingOperationsForUser, která jen tak mimochodem někde v hloubi překvapivě označovala operace za expirované.

Null

Osobně se snažím mít všechno not-null a to, co je volitelné, jasně deklarovat jako java.util.Optional, aby API bylo předvídatelné a jasně rozlišitelné, co je povinné a co ne.

Výjimky

Výjimky jsou pro výjimečné situace. Nebudu tady házet špínu na kontrolované výjimky (checked exception). Nabízím trochu smířlivější pohled z článku Everything Bad in Java is Good for You, kde tvrdí, že to není problém jazyka, ale API a že bychom je měli vyhazovat jen v případě, kdy je jasné, jak na ně zareagovat.

Nehledě na to, že exception handling má negativní dopad na výkon.

O tom, že rozbíjí functional pipeline podrobně rozebírá třeba i Venkat v knize Functional Programming in Java. Jak vhodně chyby propagovat můžeme vidět například na API reactor.core.publisher.Mono#error(). Už jsem se o tom někde zmiňoval a přiznám se znovu: Na jednom projektu jsme to před lety přehnali s tím, že se velká část byznys logiky řídila výjimkami. Dneska bych se už hodně inspiroval Reactorem.

Immutabilita

Rád bych v DTO objektech nově používal Java Records místo lombok.Data. Kromě immutability bychom měli dostat i nějaký drobný výkonností bonus (ne na výplatě, ale v JVM), viz Java Records are “Trusted” and Consequently Faster.

Závěr

Konvertita na funkcionální programování se ze mě nestane. Ovšem principy jsou přenositelné.

Komentáře

Subscribe
Upozornit na
guest
1 Komentář
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Kit
  • Používám immutable objekty
  • Pro data místo objektů používám struktury a kolekce
  • Vyhýbám se používání null – výjimky jsou lepší
  • Používám i synchronní výjimky dle potřeby, protože jsou užitečné a zjednodušují aplikaci
  • Podprogramy dělím na procedury (něco dělají) a funkce (zjišťují stav) – nikdy nedělají obojí
  • Pro dědičnost mám přísná pravidla omezující jejich hloubku
  • Z každého pravidla existují výjimky – nejsem stroj

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.