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

Odebírat
Upozornit na
guest
1 Komentář
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
Zobrazit všechny komentáře
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

Jak zabezpečit WordPress: Praktický průvodce

WordPress pohání přes 40 % všech webů na světě. To z něj dělá nejrozšířenější CMS a zároveň nejčastější terč automatizovaných útoků. Boti nepotřebují cílit přímo na vás: systematicky procházejí miliony domén a hledají otevřené dveře. Stačí zapomenutý plugin bez aktualizace, výchozí prefix databáze nebo heslo z uniklé databáze. Tento článek není seznam pluginů. Je to průvodce od základů přes hardening konfigurace až po serverové zabezpečení s konkrétními kroky, které můžete udělat ještě dnes.

Product Engineer: supermani, nebo falešná efektivita?

Stále více firem propouští produktové týmy a sází na jednu roli, která to zvládne celé sama. Product Engineer je člověk, který vymyslí produkt, implementuje ho a vyhodnotí výsledky. S ekosystémem AI agentů místo kolegů. Efektivita? Na první pohled určitě. Ale je rozdíl mezi tím dodávat víc a rychleji a skutečně být efektivní. Tenhle rozdíl firmy zatím moc neřeší.

EU AI Act: co musí vývojářské týmy vědět do 2. srpna 2026

Druhého srpna začnou v EU platit povinnosti pro poskytovatele i provozovatele high-risk AI systémů: posouzení shody, technická dokumentace a quality management na straně providerů, uchovávání logů a dohled nad provozem na straně deployerů. Samostatně vstupují v platnost transparentní pravidla pro chatboty, generativní AI a deepfaky, a ta se týkají všech, nejen high-risk systémů. Kdo nasazuje AI v recruitmentu, credit scoringu nebo HR hodnocení, je v zóně. Čekání na odklad přes Digital Omnibus je sázka na legislativní proces, který ještě neskončil. A kdo si myslí, že se ho to netýká, protože „jen používá ChatGPT" v use casu z Annexu III, pravděpodobně špatně přečetl nařízení.