Váš názor na kombinaci několika technologií

[rhubner]

Ahoj,

Predem poznamenam ze programuji uz nekolik let v Jave a posledni 4 roky ve Scale(ale ne uplne ciste funkcionalne).

Elektronu a GO bych se nebal, jsou to uz zazite technologie a google napriklad hooodne investuje do GO. Ale s ostatnima technologiema bych trosku opatrnejsi(mozna v JS casti bych sel do Typescriptu). Ted neco napises a za 2 roky budou chtit opravu a nebudou mit na upravu tolik penez a ty na tom prodelas a nebo si udelat spatnou reputaci. Budou rikat ze to stalo tolik a tolik a ted to nemuzou pouzivat protoze chces xxx za opravu. Pripadne si muzes dohodnout nejaky mesicni udrzovaci poplatek a kazdy pulrok vydat novou verzi aby jsi predesel tomu ze ti projekt nepujde zkompilovat kdyz budes potrebovat udelat hotfix. Pokud nechteji platit udrzbu, tak jim predat i zdrojovy kod a rict ze s timhle to muzes kdokoliv upravit. Napriklad u ERP se bezne plati udrzovaci poplatek 10% rocne z implementacni ceny(vcetne dodelavek).

Jinak na backendu bych se drzel typovych jazyku. GO, Java, C#, Typescript .... Dokud je aplikace mala, tak to je sranda, ale jakmile se mi rozroste, tak se blbe dela refaktoring. V typovych jazycich to kontroluje prekladac a tak se delaji nektere opravy mnohem jednoduseji. V dynamickych jazicich je potreba psat vice automatizovanych testu.

Jako databazi bych asi pouzil SQLite. Mate silu SQL databaze a navic ji bude rozumet kazdej. Nic vam nebrani do SQLite ukladat JSON. Vykonu bych se nebal. Pokud prestane staci muzete prejit na nejakou vetsi databazi. Dokud jsou data mala(<100GB), drzel bych se SQL. Je to stabilni overena technologie a nemusite resit plno omezeni noSQL.

Radek

[Reklama]

[Zabanovaný Anonymní Troll]

Hosi jde videt ze jste fakt amateri a nevite ktera bije. Takovihle amaetori to jsou takovi ti lidi, kteri kdyby v Jave programovali, tak spatne  Java je nejvetsi nigga ze vsech otevrenych platforem, v tom co dela je nejlepsi, je to nejstandardnejsi a nejfunknejsi vec. Za to, ze programatori udelali memory leaky nemuze Java, zpusobi to predevsim debilni management, ktery nedava dostatek casu na vyvoj a na udrzbu a do tymu nedaji alespon jednoho skveleho seniora. Java v soucasnosti stale nema zadnou konkurenceschopnou alternativu pro enterpsise backend.

Amatér si možno ty, v ostatných jazykoch než Java. Bastlíš si tam nezmysli. Na kilo kódu máš 2 kilá OOP balastu, 1 kilo setterov, getterov, a nevím čo ešte. OOP samotné chyba nieje, ale tak jak je implementovaná v Jave je chyba najväčšia. Popravde, pred nedávnnom na roote bol článok k tomu, kde v podstate odslova doslova vysvetlili čo vše je v Jave nezmysel. Viď odkazy:

https://sw-samuraj.cz/2019/02/remcani-proti-jave/
https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53

(práve ten druhý a tretí link, to je jak kdyby autor prečítal môj mozog, a všetko čo si myslím o Jave napísal v článku, sám když som to čítal bol som v šoku jak presne zhodný názor na to autor má, snaď až na výnimku že funkcionálne programovanie si nezmyslím že je jediná správna cesta, ale inak...).

Ak už inak autor OOP konceptu nadáva na najviac "moderný OOP" jazyk, tak asi neco na tom bude.

Jo? A co sis teda nasel za alternativu k Jave, pochlub se, treba mate na Slovensku neco, co svet jeste neobjevil Jestli je alternativa kombinace nekolika ruznych jazyku, tak navstiv doktora 

A co se tyce OOP, tak jde videt, ze neznas nejmodernejsi metodologie organizace zdrojoveho kodu, ktere se vyvinuly v Jave za poslednich 20 let, a delali to vetsi bedny nez si ty Ty v tom proste hochu neumis  To, ze se na vsechno nehodi ultra OOP, to my experti co delame v Jave davno vime, ty ale jeste zrejme ne  Dneska je nejpopularnejsi plocha architektura, s rozdelenim na stateless tridy spojovanymi dependency injection, pojo objeky, se stridmym uzivanim typove hierarchie  A my experti v Jave, kdyz se nam to hodi, dovedeme udelat i highperformance asynchronni aplikace treba s Vertex  A ti nejvetsi experti, kdyz se jim to hodi, si muzou udelat i ultra OOP knihovnu 

Mas se synku jeste hodne co ucit

[redustin]

Odkaz 1) Java - chybí rozumně udělaná kompozice (tj. vícenásobná dědičnost). Autoři Javy to samozřejmě ví a snaží se "tunit" interfacy, ale dokud v něm nebude interní field a protected metoda, je to pořád napůl.

Maven - máme projekt s 10tis. tříd a pom.xml jen několik. Je každého věc, jak si projekt rozseká do modulů. Ano, pluginy do mavenu jsou špatně kvůli verzování, ale nakonec nikdo jej nenutí, aby používal zrovna maven.

Odkaz 2) Bylo to tu diskutované nedávno, autor píše v JS a s Javou nemá větší praktické zkušenosti, to je vidět. FP rozhodně není řešením jím uváděných problémů.

Odkaz 3) Chyby OOP ukazuje na špatných modelech dědičnosti (např. obr. https://miro.medium.com/max/500/1*o-Mdcrd9B5hTrrQKhcP8yA.png ) . Opět dochází k tomu, že chybí (de)kompozice, což chybí.

Pevně věřím, že se rozhraní v javě postupně změní na variantu traitu. Již to tak pár let od zavedení defaultních metod používáme, ale citelně chybí fieldy a protected default metody, aby se nenafukovalo API.

[Mlocik97]

Jo? A co sis teda nasel za alternativu k Jave, pochlub se, treba mate na Slovensku neco, co svet jeste neobjevil Jestli je alternativa kombinace nekolika ruznych jazyku, tak navstiv doktora 

A co se tyce OOP, tak jde videt, ze neznas nejmodernejsi metodologie organizace zdrojoveho kodu, ktere se vyvinuly v Jave za poslednich 20 let, a delali to vetsi bedny nez si ty Ty v tom proste hochu neumis  To, ze se na vsechno nehodi ultra OOP, to my experti co delame v Jave davno vime, ty ale jeste zrejme ne  Dneska je nejpopularnejsi plocha architektura, s rozdelenim na stateless tridy spojovanymi dependency injection, pojo objeky, se stridmym uzivanim typove hierarchie  A my experti v Jave, kdyz se nam to hodi, dovedeme udelat i highperformance asynchronni aplikace treba s Vertex  A ti nejvetsi experti, kdyz se jim to hodi, si muzou udelat i ultra OOP knihovnu 

Mas se synku jeste hodne co ucit

Nazývať seba expertom vypovedá o tom že expert nie si. Zaujímavé že som stretol už tucet expertov, i takých ktorý vraj programujú v Jave 10 rokov. A zaujímavé že ľubovolní 2 z nich, si každý definici OOP v Jave vysvetlil úplne inak. Každý to chápe úplne inak. A ešte aj tý medzi sebou sa hádajú, a jeden druhému tvrdí že v Jave nevie programovať. Tak potom kto vie v Jave programovať? Java je humus, kdyby nebol, nebolo by potreba sa učiť takové množstvo design patternov, refactoring by nespôsibil že kód sa zvätší viac než dvojnásobne, a nebol by v tom taký superchaos ako sa spomína v tretom článku s ešte jednoduchým kódom a už zložitým problémom o "Kopírke".
Java je grc. grc, ktorý bol ešte mnoho krát prehltnuť a znova vygrcán.
Ak si taký expert, tak určite vieš povedať čo také profesionálne si dokázal naprogramovať. Lebo zaujímavé že i autor Linuxu, ktorý je skutočný expert, moderné OOP kritizuje. Tak isto autor konceptu OOP, tak isto autor programovacieho jazyka ERLang. Atd atd. Zaujímavé že tý čo majú najlepší softvér kritizujú moderné OOP a Javu, či iné podobné jazyky ako C#, C++, PHP. Pritom kto kritizuje Golang? Len bezvýznamný programátori, čo napsali v podstate program komplexnosti "Hello World" (na kilometre ďaleko od Linuxu). Myslím že Linusov názor teda považujem že má omnoho omnoho väčšiu váhu, on sa môže nazývať profesionálom/expertom. Ty rozhodne nie. A to že všade cpeš okulárové smajlíky už jasne vypovedá o tom jak si "vyvinutý" nebo teda naopak. To čo si napsal, ma teda ešte viac ujistilo že Java je blbá, v podstate si ma presvedčil ešte viac o opaku než to čo si chcel.

[oss]

Jo? A co sis teda nasel za alternativu k Jave, pochlub se, treba mate na Slovensku neco, co svet jeste neobjevil Jestli je alternativa kombinace nekolika ruznych jazyku, tak navstiv doktora 

A co se tyce OOP, tak jde videt, ze neznas nejmodernejsi metodologie organizace zdrojoveho kodu, ktere se vyvinuly v Jave za poslednich 20 let, a delali to vetsi bedny nez si ty Ty v tom proste hochu neumis  To, ze se na vsechno nehodi ultra OOP, to my experti co delame v Jave davno vime, ty ale jeste zrejme ne  Dneska je nejpopularnejsi plocha architektura, s rozdelenim na stateless tridy spojovanymi dependency injection, pojo objeky, se stridmym uzivanim typove hierarchie  A my experti v Jave, kdyz se nam to hodi, dovedeme udelat i highperformance asynchronni aplikace treba s Vertex  A ti nejvetsi experti, kdyz se jim to hodi, si muzou udelat i ultra OOP knihovnu 

Mas se synku jeste hodne co ucit

Nazývať seba expertom vypovedá o tom že expert nie si. Zaujímavé že som stretol už tucet expertov, i takých ktorý vraj programujú v Jave 10 rokov. A zaujímavé že ľubovolní 2 z nich, si každý definici OOP v Jave vysvetlil úplne inak. Každý to chápe úplne inak. A ešte aj tý medzi sebou sa hádajú, a jeden druhému tvrdí že v Jave nevie programovať. Tak potom kto vie v Jave programovať? Java je humus, kdyby nebol, nebolo by potreba sa učiť takové množstvo design patternov, refactoring by nespôsibil že kód sa zvätší viac než dvojnásobne, a nebol by v tom taký superchaos ako sa spomína v tretom článku s ešte jednoduchým kódom a už zložitým problémom o "Kopírke".
Java je grc. grc, ktorý bol ešte mnoho krát prehltnuť a znova vygrcán.
Ak si taký expert, tak určite vieš povedať čo také profesionálne si dokázal naprogramovať. Lebo zaujímavé že i autor Linuxu, ktorý je skutočný expert, moderné OOP kritizuje. Tak isto autor konceptu OOP, tak isto autor programovacieho jazyka ERLang. Atd atd. Zaujímavé že tý čo majú najlepší softvér kritizujú moderné OOP a Javu, či iné podobné jazyky ako C#, C++, PHP. Pritom kto kritizuje Golang? Len bezvýznamný programátori, čo napsali v podstate program komplexnosti "Hello World" (na kilometre ďaleko od Linuxu). Myslím že Linusov názor teda považujem že má omnoho omnoho väčšiu váhu, on sa môže nazývať profesionálom/expertom. Ty rozhodne nie. A to že všade cpeš okulárové smajlíky už jasne vypovedá o tom jak si "vyvinutý" nebo teda naopak. To čo si napsal, ma teda ešte viac ujistilo že Java je blbá, v podstate si ma presvedčil ešte viac o opaku než to čo si chcel.

Ty musis mat z javy naozajstnu traumu, alebo ta ako maleho bili java programatori.
Odvolavat sa na Linusa, ktory je uz za zenitom je naozaj vtipne, hlavne vo svete OOP. Ked si clovek precita Clean code bude mt vetsie znalosti OOP ako Linus.
Este viac smiesny je pojem "najlepsi softver", ani omylom.
Vsteky tvoje argumenty boli vyvratene a ti si tu aj tak bezdovodne kopes do Javy, pricom tvoja povodna otazka bola o niecom uplne inom.
Hlavne, ziadnu s tych "slamenych pankov preco je OOP uplne zlo" Golang neriesi.

[Reklama]

[redustin]

nebol by v tom taký superchaos ako sa spomína v tretom článku s ešte jednoduchým kódom a už zložitým problémom o "Kopírke".

Proč by měla být kopírka potomkem tiskárny a skenneru? Kopírka je kompozitní zařízení, které uvnitř obsahuje obojí, ale rozhodně není přímým potomkem ani jednoho. Zřejmě implementuje spoustu společných rozhraní (Má napájení, má uživatelské rozhraní, atd.), ale implementace je úplně jiná. Navíc "umí tisknout" (jako tiskárna), "umí skenovat" (stejně jako skenner). Tiskárna i skenner jsou v kopírce od vnějšího světa odstíněné vrstvou kopírky. Všechno z toho lze rozpadnout do malých rozhraní, ale přímá dědičnost je rozhodně špatně. Možná to tak vypadá na první pohled, ale až by se autor dostal na detaily, zjistil by, že to v reálu dědičnost není. A každé nesprávné namodelování skutečnosti se u živého projektu jednou vymstí a bude se muset předělat. A tam nastoupí typová kontrola javy a předělání bude celkem bezbolestné a bezpečné, pokud se nepoužily nerefaktorovatelné techniky (reflexe a spol.).

[KorporatniLopata]

Každej, kdo věří tomu, že Java je na tom tak špatně jak tu prezentuje pan Mocik, by se měl striktně držet papírových peněz, protože bankovní systémy jsou postaveny z velké části na Javě. Ano, kompozice chybí a nezbývá než doufat, že Java bude pokračovat s vyzobavánim třešniček z ostatních jazyků, jak to dělala do teď. Ano, malé projekty lze napsat v něčem rychleji, ale jak roste projekt, produktivita se srovnává.
Jestli je na Javě něco super, tak že se poměrně dobře ví, kde nás tlačí bota a jak s limity jazyka pracovat.
Vůbec neberu takové ty kydy, že tvrzení X je pravda, protože to řekl Linus, spíš se snažím přemýšlet o samotném X. Nevím jak na tom je s OOP Linus, ale obecně: OOP je koncept, realizovat se dá různými způsoby, už podle toho, jak moc vnímám dědičnost jako fundamentální. Tohle je fakt diskuse na dlouho a snad by stála i za to, kdyby se vedla věcně, ale pokud někdo staví 360. e-shop v PHP, asi řeší úplně jiný typ problémů než někdo, kdo řeší infrastrukturu banky. Diskuse je pak fakt těžká.

[Mlocik97]

Každej, kdo věří tomu, že Java je na tom tak špatně jak tu prezentuje pan Mocik, by se měl striktně držet papírových peněz, protože bankovní systémy jsou postaveny z velké části na Javě.

K tomuto napíšu len jedno. Nepsal som nič o "nebezpečnosti" ale o tom jak je programovací jazyk špatný. To ale neznamená že pre uživatela je program naprogramovaný v Jave striktne "nebezpečný na použitie". Len tvrdím že to čo je naprogramované v Jave by v iných jazykoch šlo naprogramovať omnoho lepšie. To je veľký rozdiel.

Vsteky tvoje argumenty boli vyvratene a ti si tu aj tak bezdovodne kopes do Javy, pricom tvoja povodna otazka bola o niecom uplne inom.

to áno, ale kto tu prvý spomenul pojem Java? ne ja, ale "Javista".
Ešte k tomu ďalšiemu o Linusovi čo si psal. Kopíruješ moje argumenty. "Javista" tvrdí že je expert, a teraz urážate Linuse v podobnom význame? Pff... To vypovedá o logike "Javistov"...  A áno mám z Javy trauma, ako každý kto programuje udržitelný software, a nie problematický balast, u ktorého když chcete pridať nejakú funkcionalitu, tak to ovplivní beh 200 iných funkcionalít. Tady končím s kecmi o Jave. OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?

[Wavelet]

Každej, kdo věří tomu, že Java je na tom tak špatně jak tu prezentuje pan Mocik, by se měl striktně držet papírových peněz, protože bankovní systémy jsou postaveny z velké části na Javě.

K tomuto napíšu len jedno. Nepsal som nič o "nebezpečnosti" ale o tom jak je programovací jazyk špatný. To ale neznamená že pre uživatela je program naprogramovaný v Jave striktne "nebezpečný na použitie". Len tvrdím že to čo je naprogramované v Jave by v iných jazykoch šlo naprogramovať omnoho lepšie. To je veľký rozdiel.

Vsteky tvoje argumenty boli vyvratene a ti si tu aj tak bezdovodne kopes do Javy, pricom tvoja povodna otazka bola o niecom uplne inom.

to áno, ale kto tu prvý spomenul pojem Java? ne ja, ale "Javista".
Ešte k tomu ďalšiemu o Linusovi čo si psal. Kopíruješ moje argumenty. "Javista" tvrdí že je expert, a teraz urážate Linuse v podobnom význame? Pff... To vypovedá o logike "Javistov"...  A áno mám z Javy trauma, ako každý kto programuje udržitelný software, a nie problematický balast, u ktorého když chcete pridať nejakú funkcionalitu, tak to ovplivní beh 200 iných funkcionalít. Tady končím s kecmi o Jave. OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?

Máte dost nedospělý pohled na svět. Dospělý člověk řeší problém, puberťák jazyk. "OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?" Ne.

[Ondrej Nemecek]

Odkaz 1) Java - chybí rozumně udělaná kompozice (tj. vícenásobná dědičnost). Autoři Javy to samozřejmě ví a snaží se "tunit" interfacy, ale dokud v něm nebude interní field a protected metoda, je to pořád napůl.

(...)

Pevně věřím, že se rozhraní v javě postupně změní na variantu traitu. Již to tak pár let od zavedení defaultních metod používáme, ale citelně chybí fieldy a protected default metody, aby se nenafukovalo API.

Přesně tak, rozhraní může být přeci i interní, kéž by to už v javě bylo! Omezení na veřejné metody v rozhraní mi přijde dost umělé a nesmyslné. IMHO by úplně stačilo mít vícenásobnou dědičnost s tím, že by rozhraní jen kontrolovalo přítomnost metod a nic jiného nenabízelo. Tak to ale v javě nebude, to je jasné. Místo toho se namísto tříd začnou víc používat rozhraní. Trochu absurdní řešení, ale dá se s tím asi žít.

Každopádně když jsem začal používat rozhraní s default metodama (traity) dalo mi to větší flexibilitu a svobodu, ale zároveň lepší konzistenci. Je to tak trochu lék na nadužívání hiearchie tříd a nepřítomnost vícenásobné dědičnosti. Ale ve stávající podobě to stále není kompletní.

[Ondrej Nemecek]

Máte dost nedospělý pohled na svět. Dospělý člověk řeší problém, puberťák jazyk. "OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?" Ne.

Nesmysl, dospělí lidé přeci taky řeší jazyky (byť rozhodně ne způsobem vedeným v této diskuzi).

[Ondrej Nemecek]

Proč by měla být kopírka potomkem tiskárny a skenneru? Kopírka je kompozitní zařízení, které uvnitř obsahuje obojí, ale rozhodně není přímým potomkem ani jednoho. Zřejmě implementuje spoustu společných rozhraní (Má napájení, má uživatelské rozhraní, atd.), ale implementace je úplně jiná. Navíc "umí tisknout" (jako tiskárna), "umí skenovat" (stejně jako skenner). Tiskárna i skenner jsou v kopírce od vnějšího světa odstíněné vrstvou kopírky. Všechno z toho lze rozpadnout do malých rozhraní, ale přímá dědičnost je rozhodně špatně. Možná to tak vypadá na první pohled, ale až by se autor dostal na detaily, zjistil by, že to v reálu dědičnost není. A každé nesprávné namodelování skutečnosti se u živého projektu jednou vymstí a bude se muset předělat. A tam nastoupí typová kontrola javy a předělání bude celkem bezbolestné a bezpečné, pokud se nepoužily nerefaktorovatelné techniky (reflexe a spol.).

Takže můžete ty kompozitní části buď přímo vystavit  a pak je přímo voláte - copier.getScanner().scan() - anebo je schováte za rozhraní a voláte copier.scan() Druhý způsob lépe zapouzdřuje, ale přidává nějaký režijní kód navíc, kde se budou interně nejspíš jen volat metody kompozitu. V „opravdovém“ OOP by stačilo metodu přeposlat.

Při použití traitů můžete navíc, pokud jsou dobře navrženy, funkčnost skeneru přidat pouhým připojením toho traitu - s minimální nutností něco implementovat, protože sdílená funkčnost může být v tom traitu už implementovaná. Nově se bude implementovat například jen hardwarově závislá část, který zajistí získání InputStreamu apod. Zpracování a operace nad těmi daty bude v traitu. To samé pro tiskárnu. Stále při zachování toho, že kopírka nemusí dědit z tiskárny a skeneru. Pokud to shrnu, trait je v porovnání s dědičností flexibilnější způsob sdružování implementace do balíčků.

[redustin]

Každopádně když jsem začal používat rozhraní s default metodama (traity) dalo mi to větší flexibilitu a svobodu, ale zároveň lepší konzistenci. Je to tak trochu lék na nadužívání hiearchie tříd a nepřítomnost vícenásobné dědičnosti. Ale ve stávající podobě to stále není kompletní.

No jasně, dědičnost a kompozice se doplňují, to není žádná náhrada. Proto jsou úchylné ty příklady údajně nefunkční dědičnosti, když jde ve skutečnosti o kompozici a dědičnost vůbec neměla být použitá.

Defaultní metody používáme úplně stejně, workaround, ale dá se. Nicméně holt budu mít public metody místo protected a sem tam nějaký field navíc, když jej nemohu strčit rovnou k rozhraní, ale pořád radši bezpečí typového systému + generik a možnosti nabízené kvalitním IDE Javy. Až to do javy dodělají, bude triviální public změnit na protected, příp. přesunout ty duplicitní fieldy z implementací rovnou do společného rozhraní/traitu.

Navíc spoustu komponent pracuje právě s jednou funkcionalitou/rozhraním/traitem, to už lze/je potřeba mít správně oddělené dneska.

Jenže to vše vyžaduje aspoň trochu kompetentního vývojáře, který nemíchá jablka a hrušky do jedné třídy a pak si stěžuje, že mu dědičnost hází klacky pod nohy.

[Zdenek Henek]

nebol by v tom taký superchaos ako sa spomína v tretom článku s ešte jednoduchým kódom a už zložitým problémom o "Kopírke".

Proč by měla být kopírka potomkem tiskárny a skenneru? Kopírka je kompozitní zařízení, které uvnitř obsahuje obojí, ale rozhodně není přímým potomkem ani jednoho. Zřejmě implementuje spoustu společných rozhraní (Má napájení, má uživatelské rozhraní, atd.), ale implementace je úplně jiná. Navíc "umí tisknout" (jako tiskárna), "umí skenovat" (stejně jako skenner). Tiskárna i skenner jsou v kopírce od vnějšího světa odstíněné vrstvou kopírky. Všechno z toho lze rozpadnout do malých rozhraní, ale přímá dědičnost je rozhodně špatně. Možná to tak vypadá na první pohled, ale až by se autor dostal na detaily, zjistil by, že to v reálu dědičnost není. A každé nesprávné namodelování skutečnosti se u živého projektu jednou vymstí a bude se muset předělat. A tam nastoupí typová kontrola javy a předělání bude celkem bezbolestné a bezpečné, pokud se nepoužily nerefaktorovatelné techniky (reflexe a spol.).

Bingo. Kompozice. Taky jsem došel do tohoto stavu. Trvalo to, ale cesta je cíl .

Predka dvou tříd nedělám proto, abych mohl sdílet jejich "společné" metody. Kompozice a interface a společný kod do separatní třídy. Toto je v mnoha případech dostačující a mnohem lépe udržovatelné. A hierarchie vytvářím pouze pokud se jedná opravdu o nějaký subjekty s hierarchií.

I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied.

https://www.javaworld.com/article/2073649/why-extends-is-evil.html#talkback

[redustin]

interface a společný kod do separatní třídy. Toto je v mnoha případech dostačující a mnohem lépe udržovatelné.

Je, ale všichni víme, že to je workaround. Kdyby tu společnou funkcionalitu rovnou umělo ono "rozhraní", včetně dat, které by si uvnitř neslo (properties) a chovalo se jako normální trait nebo mixin... Ale ono to jednou přijde.