Remcání proti Javě

Po 3⁄4 roce práce v Golangu jsem se vrátil na chvíli k Javě. Doufám, že jen dočasně. Protože, když člověk na dostatečně dlouhý čas vypadne z prostředí, kde dlouhodobě pobýval, a vrátí se zpět, najednou mu dojde, jak jsou některé věci obskurní. A jak některé věci, které byly vymyšleny s nejlepšími úmysly pomáhat, ve skutečnosti práci zatemňují a ztěžují. Je to, jako když žijete v prasečáku a už si pak neuvědomujete, že prasata smrdí.

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

Nekonečné přelévání dat mezi vrstvami

Určitě to znáte — pokud jste v posledních 10 letech dělali nějakou “klasickou” webovou aplikaci v Javě, je všechno rozděleno do vrstev a mezi těmi vrstvami si předáváte data. Data, která přijdou z webové služby nebo z GUI, následně přechroustáte v business logice a uložíte.

Na každou z těch vrtev nejspíš používáte nějaký framework a ten framework… očekává data v určitém formátu/struktuře (typicky POJO, protože OOP, že jo), nebo s určitými metadaty (anotační rakovina).

Takže ty pořád stejný hodnoty (nejspíš nějaký String, nebo int) posíláte kaskádou vrstev tam a zpátky. K tomu je nejspíš(?) pořád(?) validujete a ošetřujete chyby. (Nebo na to kašlete?). A to všechno jen proto, že vám to diktuje nějaký framework nebo design pattern.

Mimochodem, pokud jste se nad tím někdy zamýšleli, dobrá polovina návrhových vzorů existuje jenom proto, aby řešila problémy objektového programování. Existují jazyky (třeba Ruby  nebo Clojure), kde většina návrhových vzorů nedává smysl.

Proliferace modelových tříd

S výše zmíněným problémem souvisí, že všechno to přelévání dat mezi vrstvami musíte realizovat pomocí modelových tříd, které… nejen že na sebe “nesedí” (tuhle jeden field chybí, támhle druhý přebývá), ale jsou inherentně jiného typu. Takže vezmete do ruky lopatu a pěkně ručně, nebo nějakým mapovacím frameworkem ty data přehážete z jednoho modelu do druhého. A to nemluvím o tom, že často ty třídy vracíte v nějaké kolekci.

Proč je problém, že jsou modelové třídy různého typu? Občas se to tak pěkně sejde, že máte dvě takovéhle třídy:

public class HistoryRecord  {
    @JsonProperty("opcRequestID")
    private String id;
    @JsonProperty("namespaceName")
    private String namespaceName;
    @JsonProperty("bucketName")
    private String bucketName;
    // Rest of the class is ommitted.
}

@KievEntity
public class ObjectSelectHistoryEntity {
    @HashKey
    @Column(type = ColumnType.STRING, length = 255)
    private String id;
    @Column(type = ColumnType.STRING, length = 255)
    private String namespaceName;
    @Column(type = ColumnType.STRING, length = 255)
    private String bucketName;
    // Rest of the class is ommitted.
}

Všimněte si, že obě třídy obsahují naprosto identické členy — jak názvem, tak typem. Je vám to k něčemu? Ne. Prostě vezmete do ruky lopatu… Smutné je, že většinou nad těmi hodnotami nepotřebujete dělat žádné transformace, chcete jenom dostat data od uživatele do databáze.

Proč k tomu dochází? Na jedné straně máte dejme tomu SwaggerJAX-RS apod. a na druhém konci je nějaká (No)SQL perzistence, často zastřešená ORM abstrakcí. Takže HibernateSpring Data atd.

Všechny tyhle věci vám generujou, nebo očekávají… hádejte co? Ano, modelové třídy. A do těch modelových tříd generujou, nebo v nich očekávají… hádejte co? Ano, metadata (tj. anotace). A od vás, jako programátora, očekávají… hádejte co? Ano, že vezmete do ruky lopatu a…

Starý dobrý Maven

Řeknu vám, že jestli jsem na něčem poslední roky tvrdě pracoval, tak na tom, aby bylo jasné, že jsem Maven kverulant. Já si prostě nemůžu pomoct — vždycky, když vidím nějakého spokojeného uživatele Mavenu, tak si musím (přátelsky) rýpnout.

Protože, upřímně soudruzi, který buildovací, nebo automatizační nástroj umožňuje, ba pobízí uživatele k takovémuto projektovému designu:

Je to tak: na 99 Java souborů (z nichž tak třetina až polovina je výše zmíněný OOP balast) je potřeba 23 Maven konfiguráků! Či jinými slovy, 17 Maven modulů produkujících JAR. Ani vám nebudu ukazovat projektovou hierarchii, protože kdybych si vyjel:

tree -P pom.xml -I 'src|target'

tak se mi to nevejde na obrazovku notebooku. Jen vám řeknu, že ta hierarchie je tříúrovňová.

No, a kdybych se ještě pustil do toho, jak skvěle se tuní Maven pluginy, tak bychom tady byli ještě zítra. Jenže to už by nebylo remcání… to by byla svatá válka!

Kam ten svět spěje?

Řekl jsem dneska něco pozitivního? Ne, neřekl. Ale to neznamená, že bych Javu neměl celkem rád — za těch 12 let, co jsme spolu zatím strávili, by bylo divné, kdybychom se čas od času nepoškorpili. Když pominu svoji ženu, tak Java je vlastně jeden z nejdelších vztahů, který jsem kdy měl. 😈 Za tu dobu, už člověk ztratil iluze a ví, jak to v životě chodí. A naučí se být trochu tolerantní.

Poslední rok píšu micro-services v Golangu. Předtím jsem (sekvenčně) programoval 2 roky v JavaScriptu, 3 roky v PHP a 12 let v Javě. Paralelně k tomu jsem 8 let fungoval jako Team/Technical Leader. Píšu technologický blog SoftWare Samuraj, kde se věnuji různým aspektům z oblasti SW engineeringu.

Komentáře: 24

Přehled komentářů

Vít Heřman
tmysik Škoda, že...
Martin Hassman Re: Škoda, že...
Vít Kotačka Re: Škoda, že...
Tobiáš Potoček Lze psát stejný kód v Javě jako v Golang?
Vít Heřman Re: Lze psát stejný kód v Javě jako v Golang?
balki Re: Lze psát stejný kód v Javě jako v Golang?
Vít Kotačka Re: Lze psát stejný kód v Javě jako v Golang?
Vít Kotačka Re: Lze psát stejný kód v Javě jako v Golang?
Vít Heřman Re: Lze psát stejný kód v Javě jako v Golang?
Tobiáš Potoček Re: Lze psát stejný kód v Javě jako v Golang?
Vít Kotačka Re: Lze psát stejný kód v Javě jako v Golang?
Tobiáš Potoček Re: Lze psát stejný kód v Javě jako v Golang?
Vít Kotačka Re: Lze psát stejný kód v Javě jako v Golang?
Tobiáš Potoček Re: Lze psát stejný kód v Javě jako v Golang?
atamiri Re: Lze psát stejný kód v Javě jako v Golang?
Vít Kotačka Re: Lze psát stejný kód v Javě jako v Golang?
Oldisy3
Richard Šindler
Balki Re:
oldjay Tak opravdu jenom hádám
Vít Kotačka Re: Tak opravdu jenom hádám
Mlocik97 Díky za článek
Vít Kotačka Re: Díky za článek
Zdroj: https://www.zdrojak.cz/?p=22708