Omnadrenowy Rycerz napisał(a):
Obiecaj, że nic już nie oddzieli nas,
Tak jak pisałem 100 razy temu.
Java uczy OOP czyli tego jak to się nazywa programowania obietkowego.
Jak ktoś tego się nauczy to każdy zespół go przyjmie do pracy, bo będzie dobrym do pracy zepołowej.
BO taka akurat takie jest obiektowe porgramowanie czyli oop.
Ale OOP już jest passe, teraz się pisze funkcyjnie.
Ale OOP już jest passe, teraz się pisze funkcyjnie.
Wątpię. Sednem programowania funkcyjnego nie są funkcje wyższych rzędów tylko niemutowalne struktury danych. Dla sensownej wydajności powinny to być trwałe struktury danych (persistent data structures) ze strukturalnym współdzieleniem (structural sharing). Ile języków ma takie w standardzie? Scala, Haskell, pewnie też Erlang, F#, a reszta to egzotyka.
Oczywiście można używać bibliotek z takimi zestawami struktur danych jak np:
ale te biblioteki nie są raczej mega popularne.
Elementy minimalnego programowania funkcyjnego w Javie są używane tylko ze względu na czytelność i prostotę. Lubimy immutable obiekty, bo są proste: nie trzeba nic synchronizować, equals i hashcode jest trywialny do implementacji. Strumienie, które w sumie są lekko funkcyjne wcale nie są wydajeniejsze od pętli, po prostu dobry kod za pomocą stream API może być wyjątkowo czytelny. Oczywiście nie ma nic za darmo, tworzenie kopii jest bardziej kosztowne niż zmiana stanu mutowalnego obiektu. Poza tym nie wierzę, aby ktoś zaczął stosować funkcyjne podejście do IO monady itp. to jest mom zdaniem nieczytelne i niepraktyczne. Efekt uboczny to efekt uboczny, dlaczego więc na siłę używać funkcyjnych bytów?
Uważam, że kod imperatywny to nie jest nic złego, zwłascza jak komuś zależy na wydajności.
margor90 napisał(a):
Oczywiście nie ma nic za darmo, tworzenie kopii jest bardziej kosztowne niż zmiana stanu mutowalnego obiektu. Poza tym nie wierzę, aby ktoś zaczął stosować funkcyjne podejście do IO monady itp. to jest mom zdaniem nieczytelne i niepraktyczne. Efekt uboczny to efekt uboczny, dlaczego więc na siłę używać funkcyjnych bytów?
Uważam, że kod imperatywny to nie jest nic złego, zwłascza jak komuś zależy na wydajności.
Po wycieczce w języki funkcjne lub choćby VAVR w javie - powrót do kodu mutowalnego przypomina spacer po polu minowym. Podobne odczucie jak po przesiadce z Javy na JS (brak typów to podobna mina). Trudno to docenić z perspektywy "gorszego" języka. jak w samochodzie - nikomu bardzo nie przeszkadza skrzynia manualna, puty nie pojeździ dłużej automatem.
A co do kosztów - paradoksalnie użycie VAVR (niemutowalne kontenery) powoduje, że moje programy są wydajniesze, bo inaczej w starych projektach (na java.util) praktycznie co chwilę robie defensywne kopie (sicher ist sicher). Prawdopodobnie 3/4 tych kopii jest bez sensu... ale nigdy nie wiadomo przed czasem. Dodatkowo funkcyjne struktury danych powodują, że tego kopiowania praktycznie nie ma - tak są zakodowane.
Tak czy siak w typowym biznesowym kodzie, gdzie listy,mapy mają po 10-200 elementów nie ma nawet nad czym się zastanawiać. Dodatkowy koszt kopiowania (w java.util) lub użycia funkcyjnych struktur danych jest pomijalny w porównaniu do zysków.
Są miejsca, gdzie kod imperatywny.mutowalny robi sie nawet w haskellu - ze względów wydajnościowych. Ale to są miejsca bardz specyficzne - grafika, machine learning etc... Nie przy dodawaniu produktu do koszyka.
@margor90:
Mnie też monady IO nie przekonują. Nie trzeba popadać ze skrajności (mutowalność na każdym kroku) w skrajność (opakowanie efektów ubocznych w monady IO).
Argument o wydajności jest średni bo zwykle ważna jest złożoność obliczeniowa (rząd wielkości, a nie pracowite zbijanie stałej) oraz skalowalność. Niemutowalne obiekty ułatwiają tworzenie skalowalnych aplikacji.
Można mieszać podejście imperatywne z funkcyjnym. Scala jest językiem, w którym obu podejść się wygodnie używa. Użycie mechanizmu aktorów pozwala na dość naturalne połączenie mutowalności (aktor zmienia stan po otrzymaniu wiadomości, także od samego siebie) z niemutowalnością (wszelakie funkcje można oprogramować używając niemutowalnych struktur danych, a przejścia między stanami aktora można zaimplementować używając Actor.become). Duży minus Akki jest taki, że jedyne oficjalnie wspierane aktory dalej są nieotypowane, ale trwają intensywne prace nad Akka Typed i jest już nawet dokumentacja: https://doc.akka.io/docs/akka/2.5/testing-typed.html
Czytelność jest prawie zawsze ważniejsza niż wydajność: to oczywiste kod jest po to, aby go czytać. Miałem okazje przez niecały rok pracować z nową Javą i zdecydowanie preferuje funkcyjny styl, gdzie mogę pisać logikę z użyciem strumieni. Trochę jak SQL. W Javie 9 dodali zdaje się całą grupę niemutowalnych kolekcji, co uważam za najważniejszą zmianę w nowym standardzie. Pytanie czemu tak późno? Ok była Guava, ale tak średnio kompatybilna z wieloma popularnymi bibliotekami: próbowałem używać, dałem sobie spokój, bo często biblioteka nie była przygotowano na niemutowalną impelmentację popularnego interfejsu).
Nawet Git napisany przez fanatycznego programiste niskopoziomowego (na wydajności się zna) robi kopię, gdzie się da i prawdopodobnie używa niemutowalnych struktur: zasłyszane na miękkiej prezentacji na jednej z konferencji.
Nie widzę powodów, aby preferować styl imperatywny i w zasadzie preferuje strumienie i lambdy wszędzie tam, gdzie nie potrzebuje efektów ubocznych. Jednocześnie nie boli mnie jak dla prostych kodów zobaczę zwykłą pętle zamiast strumienia. Różnica jest dla bardziej skomplikowanych wyrażeń przy różnych mapowaniach, filtrowaniach itp.
Monady IO - raczej chyba się w Scali nie używa, bo nie ma sensnu. IO ma sens w językach funkcyjnych i raczej jest koniecznością, a nie "wygodą".
W czystem jezyku trudno by było bez monady IO zrobić nawet prosty kalkulator BMI, bo w w takim np. kodzie:
//siakis pseudojezyk
println("podaj wage")
int waga = readLine()
println("podaj wzrost" )
int wzrost = readLine()
...
Kompilator mógłby stwierdzić, że przecież dwa razy wywołujemy readLine, bez argumentów, więc na pewno wynik jest ten sam (bo języki czyste zakładają, że funkcja wywołana z tymi samymi argumentami zwraca ten sam wynik). .. więc zrobiłby tylko jedno wywołanie i podstawił ten sam wynik w obu miejscach.
Do du..y z takim kalkulatorem!
Nie mówiąc o tym, że mógłby sobie przemieszać kolejność println i najpier poprosić w wpis z klawiatury, a dopiero potem zrobić stosowny println.
Z monadą IO jakkolwiek, readLine i inne funkcje wejścia/wyjścia przyjmują dodatkowy parametr IO i zwracaja wynik w postaci zmodyfikowanego "stanu" IO.
IO<Void> startIO = ..
IO<Void> p1 = println(startIO, "podajWagę")
IO<String> waga = readLine(p1)
IO<Void> p2 = println(waga, "podajWzrost")
IO<String> wzrost = readLine(p2)
Po czymś takim, kompilator nie ma jak "uprościć/ zoptymalizować" i musi zrobić podane operacje IO w podanej przez nas kolejności.
Troszke takie przekazywanie sobie berła między wywołaniami. Technicznie sam obiekt IO - jest pustym obiektem, znacznikiem.
W pewnym sensie Monada IO to tylko głupia sztuczka, ratująca tyłek w językach czysto funkcyjnych.
W jezykach imperatywnych kompilator i tak nie ma pola do popisu i nie może za wiele sam przestawiać (bo kto wie co by się wywaliło), dlatego cała ta zabawa w berło IO nie ma sensu.
A może raczej, nie jest niezbędna. Może jest jakiś sens "deklarowania" tego, że bawimy się w IO... ale ja sensownego zysku na razie nie widze.
W Javie 9 dodali zdaje się całą grupę niemutowalnych kolekcji, co uważam za najważniejszą zmianę w nowym standardzie.
Są niemutowalne, ale dalej nie ma structural sharing i funkcyjnego podejścia. W programowaniu funkcyjnym dodanie elementu do mapy nie zmienia poprzedniej mapy, a tworzy nową z wpisami ze starej mapy + nowym wpisem (ewentualnie nadpisującym stary).
W Javce 9 java.util.Map.put(key, value) zwraca wartość starego klucza, a nie nową, oddzielną wersję mapy. Niemutowalne mapy w Javie 9 po prostu rzucają Exception gdy się próbuje je zmienić.
Vavr.io natomiast ma niemutowalne mapy ze strukturalnym współdzieleniem i zachowujące się jak funkcyjne mapy. io.vavr.collection.Map.put(key, value) zwraca nową mapę, nie zmieniając starej.
Strukturalne współdzielenie nie jest niezbędne do wygodnego programowania funkcyjnego, ale czyni je znacznie bardziej praktycznym. Mając współdzielenie nowa mapa korzysta z elementów starej mapy (nie jest to problemem, bo obie są niemutowalne). Zakładając, że mapa jest oparta o zrównoważone drzewo binarne to tworzenie nowego drzewa wymaga tylko stworzenia nowej ścieżki od korzenia do liścia, gdzie każdy węzeł korzysta z poddrzew ze starego drzewa. Ścieżki w zrównoważonych drzewach binarnych mają długość logarytmiczną i przez to złożoność obliczeniowa jak i pamięciowa tworzenia nowego drzewa z dodanym nowym elementem jest logarytmiczna.
Dokładnie: te kolekcje "niemutowalne" w Javie 9 i wcześniej to żart. One są niemutowalne, tylko na poziomie runtime... zmiana rzuci Exception, natomiast pisząc kod tego nie widać. Dostajemy List po wywołaniu jakiejś funkcji i zgaduj mutowalna czy nie. Pisanie "bezpieczne" z użyciem niemutowalnych kolekcji z java.util., o ile jest możliwe to niestety jest niewygodne i produkuje ekstrmalnie nieefektywny kod z wieloma nonsensowenymi kopiami.
Jak teraz czytam to rzeczywiście słabo, że w JDK 9 nie stworzyli oddzielnego interfejsu dla niemutowalnych kolekcji (coś co ma Scala).
A jak to jest z Kotlinem 1.0 (którego się uczę jako dodatek do Springa)? Czytam sobie, że domyślnie mamy tam read-only kolekcje (co jest nieco mniej niż immutable). Zaleta jest taka, że wymuszamy dość porządny design za pomocą w miarę porządnego API: spoko do typowego, bieznesowego kodu. Wada jest taka, że nie mamy żadnych gwarancji odnośnie thread-safety. Dużą zaletą jest, że o modyfikowalne kolekcje należy poprosić wprost: co wymusza nieco lepszy design.
Czy po stronie Kotlina Waszym zdaniem sprawa też została spaprana, że nie stworzono tak jak w Scali dwóch oddzielnych interfejsów dla mutowalnych i niemutowalnych implementacji? Poszło o wydajność?
Czy po stronie Kotlina Waszym zdaniem sprawa też została spaprana, że nie stworzono tak jak w Scali dwóch oddzielnych interfejsów dla mutowalnych i niemutowalnych implementacji? Poszło o wydajność?
W Scalowej hierarchii kolekcji są interfejsy wspólne oraz dziedziczące po nich mutowalne i niemutowalne (przez co wydajność mutowalnych kolekcji nie powinna cierpieć z powodu obecności niemutowalnych kolekcji). Kolekcje w Scali są z jednej strony głównym narzędziem do programowania funkcyjnego, a z drugiej strony głównym powodem niekompatybilności między kodem Javowym, a Scalowym (ale są JavaConverters do opakowywania kolekcji z jednej i drugiej hierarchii).
Kotlin jest raczej nastawiony na maksymalną kompatybilność z kodem Javowym, więc biblioteka standardowa Kotlina rozszerza tą Javową zamiast ją zastępować. Nie powiedziałbym więc, że Kotlin coś spaprał. Po prostu ciężko jest nadbudować istniejące obecnie hierarchie z biblioteki standardowej Javy tak by wygodnie programowało się funkcyjnie. To samo dotyczy C# i wielu innych języków, bo zdecydowana większość kodu nie jest przystosowana do pracy z trwałymi strukturami danych.
Własna hierarchia kolekcji w Scali jest z jednej strony wadą, bo trzeba używać wrapperów na kolekcje Javowe, ale jest też zaletą bo jest sensowne API do programowania funkcyjnego. W przypadku Scali sensowne API ma większą wartość niż kompatybilność z Javą, bo Scala kładzie mocny nacisk na programowanie funkcyjne. Kotlin wybrał inny kompromis, bo miał inne założenia.
Teoretycznie twórcy Javy mogliby pokusić się o rozbudowanie hierarchii kolekcji tak by przypominała Scalową, jednak ciężko na szybko wyobrazić sobie jakie mogłyby być tego konsekwencje i czy dałoby się to sensownie zaprojektować w Javie. Vavr.io ma zupełnie osobną hierarchię kolekcji co mocno upraszcza sprawę ich projektowania.
Nie zagłębiam się w temat, ale ostatnie odpowiedzi dotyczą Kotlina i Scali. Trochę chyba odejście od tematu zwłaszcza, że Java to obiektówka, a Scala podejście funkcyjne.
Raczej pytanie powinno być takie: "Czy tworzy się nowy soft w Javie?" - nie pracowałem, ani nigdzie nie pracuję jako programista, ale słyszałem, że nikt nie chce bawić się w maintenance, ani babrać w legacy
Nie zagłębiam się w temat, ale ostatnie odpowiedzi dotyczą Kotlina i Scali. Trochę chyba odejście od tematu zwłaszcza, że Java to obiektówka, a Scala podejście funkcyjne.
Scala łączy podejścia funkcyjne i obiektowe. Obiektowości w Scali jest bardzo dużo.
Raczej pytanie powinno być takie: "Czy tworzy się nowy soft w Javie?" - nie pracowałem, ani nigdzie nie pracuję jako programista, ale słyszałem, że nikt nie chce bawić się w maintenance, ani babrać w legacy
Jeśli chcesz uniknąć maintenance i legacy to pisz studentom programy na zaliczenie. Każdy poważny projekt jest rozwijany przez wiele lat. Stary, działający kod rozwiązuje wiele problemów, które nie były oczywiste w momencie ich planowania (jeśli ktoś pracuje nad jakimkolwiek nietrywialnym projektem to wie, że oszacowania długości zadania mocno rozmijają się z rzeczywistością właśnie z powodu problemów, których od razu nie przewidzieliśmy). Z tego powodu przepisywanie dużych systemów od zera często jest samobójczym pomysłem.
Microsoft Windows jest rozwijany od roku 1985 i wątpię by w którymkolwiek momencie był przepisany od zera. Podobnie z innymi projektami jak np Mozilla Firefox - layout engine powstał w 1997 roku w C++ie i jest ciągle rozwijany, aktualnie nawet przepisywany po kawałku w Ruście: Gecko
Duże, wiekowe projekty jak np Microsoft Windows mają swoje patologie, jak np implementowanie przycisku do wyłączania Windowsa Visty przez cały zespół ponad rok czasu: The Windows Shutdown crapfest. Mimo takich patologii Microsoft i tak rządzi w segmencie PC, bo każdy kto chciałby napisać swojego Windowsa od zera napotkałby podobne problemy, a projekt trwałby na tyle długo, że też ktoś okrzyknąłby go mianem legacy, a pracy nad nim maintenance.
Z punktu widzenia korporacji najlepiej wybierać takie języki, w których napisane projekty mogą przeżyć 10 lat albo i więcej bez przepisywania od zera.
Kontynuując powyższy wątek (Java a legacy code) dodam, że są języki które wspierają długowieczność projektu i są takie które ją blokują.
Te pierwsze to np. COBOL, Pascal, Java. Cechuje je prostota składni i przewidywalność.
W tych drugich nie pracowałem za dużo, ale mogę sobie wyobrazić że ktoś mógłby do nich zaliczyć PHP i JavaScript. Może też C/C++.
Linux (język C) jest chlubnym przykładem długowiecznego projektu, ale tam są naprawdę dobrzy zawodnicy, nie wiem czy gdyby miał być rozwijany przez juniorów to coś by z tego wyszło. A w takiej Javie juniorów teraz dużo, bo każdy chce dostać te 15k ;-) - i jakoś daje radę.
Dla mnie projekt, który nie przechodzi w utrzymanie jest pewnego rodzaju porażką (chyba, że mówimy o proof-of-concept / R&D), ponieważ znaczy to, że nikt go nie używa. W praktyce to czego nie lubią programiści to nie jest wcale utrzymanie: jak się samemu rozwijało system to nawet super sprawa, bo pozwala obserwować efekty pewnych decyzji, praktyk, nieustannie ulepszać to co nie do końca działa itp. Pewne pomysły najlepiej są weryfikowane dopiero wtedy, gdy system trafia na produkcję.
Z drugiej strony zawodowo chcę pracować nad nowymi featurami, niekoniecznie do nowego systemu, niekoniecznie w najnowszych technologiach. Wiadomo, fajnie poznawać nowości, ale to nie jest najważniejsze.
To czego programiści nie lubią to utrzymywanie wielotysięczników (przesadnie rozbudowane klasy i metody o przesadnej złożoności cyklometrycznej) w aplikacjach, w których nikt nie wie jak działają. Zwłaszcza, gdy w pobliżu nie ma analityków, a wiedzę o tym jak działa obcy system trzeba wyciągać bezpośrednio od użytkowników. Jeśli jest możliwość refactoru takiego systemu to też może być wyzwanie, ale na produkcji to zabójstwo, chyba że są dobre testy.
Burdzi0 napisał(a):
Raczej pytanie powinno być takie: "Czy tworzy się nowy soft w Javie?" - nie pracowałem, ani nigdzie nie pracuję jako programista, ale słyszałem, że nikt nie chce bawić się w maintenance, ani babrać w legacy
Przyznaję, że lubie babrać się w legacy.
Najlepsze to takie kobyły, z jakimś ultra genialnym własnym frameworkiem, który jest zupełnie niedostosowany do tego co projekt robi, ale jakimś dziwnym trafem projekt zdobył miliony klientów, serwery ledwo dyszą i trzeba to naprawiać i dodawać nowe funkcje. Za wszelką cenę :-).
vpiotr napisał(a):
Kontynuując powyższy wątek (Java a legacy code) dodam, że są języki które wspierają długowieczność projektu i są takie które ją blokują.
Te pierwsze to np. COBOL, Pascal, Java. Cechuje je prostota składni i przewidywalność.
W tych drugich nie pracowałem za dużo, ale mogę sobie wyobrazić że ktoś mógłby do nich zaliczyć PHP i JavaScript. Może też C/C++.Linux (język C) jest chlubnym przykładem długowiecznego projektu, ale tam są naprawdę dobrzy zawodnicy, nie wiem czy gdyby miał być rozwijany przez juniorów to coś by z tego wyszło. A w takiej Javie juniorów teraz dużo, bo każdy chce dostać te 15k ;-) - i jakoś daje radę.
Java jest bardzo ładnym językiem, można pisać w niej śliczne programy... ale...
Programy w C++ są 3 razy szybsze? No ciekawe, mam wrażenie że troll :)
-Programy w javie sa szybsze
-Co? Jak to?
-No tak o kilka miesiecy
Odpiszę bo mam akurat ochotę :P
Oracle robi cyrk z licencjonowaniem
OpenJDK jest na licencji GPL2 + Classpath Exception. Od wersji 8 OpenJDK jest praktycznie tym samym co Oracle JDK. Z wersji na wersję jest coraz bliżej (pomijając komercyjne dodatki, których 99.9% użytkowników Javy nie używa). IntelliJ lata na OpenJDK 8 i działa bardzo dobrze.
Pisząc w Javie 80% kodu jest napisane po to aby działało pozostałe 20%. To nic złego. Ale są takie języki w których mogę zrobić to samo 5x zwięźlej.
Niektórzy piszą 5x więcej kodu, bo myślą, że tak jest lepiej. Nie znaczy to, że w Javie nie da się pisać czytelnie i w miarę zwięźle. Oczywiście składnia Javowa nadal nie jest jakaś mocno zwięzła, ale jest jakiś postęp. W Javie 7 diamond operator, w Javie 8 lambdy, w Javie 10 vary, itd Za kilka lat być może dorzucą coś a'la case class ze Scali i nie trzeba będzie korzystać z Lomboka.
Ostatnio z Javy usuwane są różne fajnie/niefajne rzeczy - czyli jest coraz mniej Javy w Javie (np. nie ma apletów - no ja tam nie płaczę za nimi - ale gdy powstawała Java to aplety miały być "tym czymś przez co Java jest fajna"). Podobnie z JavaFX - miało być fajnie - jest jakoś... dziwnie.
Aplety zginęły dawno. Flash zginął niedawno. HTML5 zastąpił oba całkowicie.
JavaFX jest dość niszową technologią, bo Java na desktopy jest rzadko spotykana. Najczęściej to chyba w postaci programów opartych o Swinga (vide IDE od JetBrains, typu IntelliJ, WebStorm, PyCharm, Rider, etc). W ogólności desktopowe GUI jest zastępowane przeglądarkowym, a Oracle widocznie niespecjalnie widzi sens by z tym walczyć.
Byle jak pisać w Javie nie jest trudno - w końcu to takie C++ dla ubogich plus GC i kupa bibliotek.
Trudność przenosi się gdzie indziej. Zamiast tracić energię na pilnowanie wskaźników, układanie bajtów i wymyślanie koła od nowa jak w C++, Javowcy skupiają się na dostarczaniu funkcjonalności biznesowych.
Wibowit napisał(a):
Trudność przenosi się gdzie indziej. Zamiast tracić energię na pilnowanie wskaźników, układanie bajtów i wymyślanie koła od nowa jak w C++, Javowcy skupiają się na dostarczaniu funkcjonalności biznesowych.
Zamiast tracić energię na pilnowanie wskaźników (...) programiści Java tracą ją na 10 warstw abstrakcji żeby osiągnąć ten sam efekt, który w przyjemniejszym języku (nie każdym) nie wymaga takiego nakładu pracy. Amen. :P
Hispano-Suiza napisał(a):
Wibowit napisał(a):
Trudność przenosi się gdzie indziej. Zamiast tracić energię na pilnowanie wskaźników, układanie bajtów i wymyślanie koła od nowa jak w C++, Javowcy skupiają się na dostarczaniu funkcjonalności biznesowych.
Zamiast tracić energię na pilnowanie wskaźników (...) programiści Java tracą ją na 10 warstw abstrakcji żeby osiągnąć ten sam efekt, który w przyjemniejszym języku (nie każdym) nie wymaga takiego nakładu pracy. Amen. :P
Nowotwór już dawno przeniósł się na inne języki. Pythonowcy, C++owcy, JavaScriptowcy, itd też mają swoje ORMy, mocki, magiczne kontenery IoC, nadmiarowe klasy (a jak są to i interfejsy) i inne dziwactwa. Rak ogarnął większość IT, ale na szczęście Scala jest jeszcze dość zdrowa :)
Hispano-Suiza napisał(a):
Zamiast tracić energię na pilnowanie wskaźników (...) programiści Java tracą ją na 10 warstw abstrakcji żeby osiągnąć ten sam efekt, który w przyjemniejszym języku (nie każdym) nie wymaga takiego nakładu pracy. Amen. :P
Ty się śmiej - wiesz jaka jest zagwozdka jak zdarzy mi się wrzucić taki prostszy kod w Javie? Nie ma DTOsów, mapperów, wzorców, interfejsów (bo mam tylko jedną implementację). Itp. Normalnie przy rewiev KONSTERNACJA. Fakt, że ostatnio to spojrzenie pod nazwą - przecież to nie może być tak proste... widziałem z rok temu.
Bo jednak, jakoś tak, przeważnie dostosowuje się do stylu i lecę z tym AbstractControllerVisitorFactoryManagerBuilderBeanImpl.
@jarekr000000: czy na Twoim githubie można znaleźć projekt, w którym nie wykorzystujesz DTOsów mapperów itp?
https://github.com/javaFunAgain/ratpong/tree/master/src/main/java/pl/setblack/pongi/scores
w tym module obiekt trwały jest jednoczesnie dtosem, api - https://github.com/javaFunAgain/ratpong/blob/master/src/main/java/pl/setblack/pongi/scores/UserScore.java
(normalnie encja na twarz :-)... tylko, że jednak nie).
Dla odmiany w module users
https://github.com/javaFunAgain/ratpong/tree/master/src/main/java/pl/setblack/pongi/users
mamy NewUser, LoginData etc., które de facto są DTOsami
oraz UserData, który jest utrwalany.
Czyli dla uścislenia DTOsy logiczne i nawet jakieś mapowania to mam :)
Natomast, zupełnie nie mam (typowych w javowych potworach) w podwzorców postaci:
MyEntity, MyEntityDTO, MyEntityCRUDRepository, MyEntityMapper itd. aż do porzygu.
Powiedziałbym, że główna różnica jest w nazewnictwie i w schemacie powstawania.
Nie zaczynam od modelowania domeny, tylko od API. Dlatego jak już coś załapie sie na przyrostek to powiedzmy encja, a nie w sumie najważniejszy komunikacyjnie obiekt.
Warto zauważyć, że w podanym kodzie nie ma żadnego API typu CRUD. Uważam, że CRUDy powstają głównie, kiedy nie myśli się o użytkowniku API,
tylko bezmyślnie eksponuje swoją wewnętrzna ( i w sumie nie tak istotną ) metodę składowania danych.