Java EE - początek nauki.

@Pinek: w sumie czasami sięe tak robi, np. przekazuje sie Comperator ale generalnie jestem przeciwny nadmiernemu stosowaniu tego rozwiązania, sprawia że kod jest mniej czytelny zwiększa niepotrzebnie liczbę argumentów i ogólnie jest to jakieś takie dziwaczne :D
Moim ulubionym podejściem jest stworzenie konstruktora, wstrzyknięcie wszystkich zależności przez niego i dodatkowo te zależności powinnny byc inteferjsami a pola final :)

Jednym z najzabawniejszych Kargo Kultów jaki widzę w JavaEE i Spring jest właśnie tworzenie interfejsów do każdego beana. Jeśli w systemie jest tylko jedna implementacja... to naprawdę ciężko wymyślić wytłumaczenie. Ale ludzie tak robią, bo to się wydaje spoko profesjonalne. A kto wie kiedyś może będzie drugi CustomerServiceBeanImpl2 :P...

A powód jes banalny - w zamierzchłym EJB / JavaEE ( i chyba , bo teraz nie moge znaleźć dokładnie kiedy - w starym Springu*). nie dało się inaczej tych beanów wstrzyknąć, wykorzystać. Żeby zadziałało Dynamic Proxy - musiał być interfejs. Tylko potem weszło w użycie cglib i problem zniknął - już nie było potrzeby pisania tych interfejsów. A tradycja mimo to przetrwała :-)

(*Update: W springu był cglib od wersji 1.0. Inna sprawa, że w zależności czy użyty był cglib czy proxy z JDK są minimalne różnice w działaniu - magia jest inna. * )

Od kilku dni bawię się Springiem, napieram RESTy, sadzę adnotacje, mockuje wszelkie testy. Nawet mi się zaczęło to podobać. Teraz czytam Was i znowu mam zrytą banię. :D

A skoro ja mam, to autor tematu już chyba do działu Javy nie zajrzy na tym forum..

Taki temat na forum mamy średnio raz na tydzień. Ogólnie mi nie robi większej różnicy czy pisze w Springu czy JEE, tylko adnotacje się zmieniają. Zgadzam się, że programowanie oparte na proxy / instrumentacji bajt-kodu jest zbyt skomplikowane i nieprzyjemne. Też podoba mi się kierunek w jakim zmierza Spring. Oby tak dalej. W JEE 9 też potencjalnie jest szansa na ciekawe rzeczy jak standaryzacja obsługi wielu tenantów, NoSQL, centralnej konfiguracji (typowe wzorce do mikrousług). Jak community się za to weźmie to może będzie ok (fundacja Eclipse). Jak JEE zrobi to dobrze to i Spring skorzysta (uważam, że póki co Spring Cloud jest zbyt skomplikowany,ale standaryzacja mogłaby pomóc).

Też liczę na popularyzacje czystego kodu javowego/kotlinowego z dala od piekła proxy i adnotacji. W końcu pozwoli się to skupić na tym co jest naprawdę ważne, czyli logice biznesowej. Serwery aplikacyjne głównie przeszkadzają.

@jarekr000000: a inny powód też jest banalny. Jesli stosujesz CGLIB to nie możesz implementacji beana zrobić finalną. A ja ja wszystkie beany robie final, z konstruktorem z argumentami i wszystkie pola są final :)

Spring swego czasu w ogóle nie wspierał cglibowych class proxy, a później tylko z odpowiednią konfiguracją. W efekcie jak miałeś jakiegoś beana z dodatkowym aspektem (czyli np. @Service + @Transactional) to juz nie działało bo spring nie był w stanie wygenerować odpowiedniego proxy dla takiej klasy, jeśli operowałeś na klasach a nie interfejsach. Nie dało się takiego beana wstrzyknąć podając typ klasy, tylko poprzez interfejs. Ale fakt, niektórym pewnie zostalo takie pisanie "na wszelki wypadek" :D
Z drugiej strony to niby takie pisanie zgodnie z zasadą Dependency Inversion Principle, poleganie na interfejsie a nie na konkretnej implementacji! ;)

Mnie dobija jak mam interfejs do beana z którego się korzysta, mam beana, ale ten bean już nie implementuje tego interfejsu bo po drodze jest jakaś magia która powoduje że ten interfejs jest opcjonalny. Czyli wywołuję nie-wiadomo-co.

@jarekr000000 -> jest wytłumaczenie, i to całkiem uzasadnione. Ja na przykład wypracowałem sobie taki styl programowania zupełnie niezależnie od Spring/JEE, aby rozwiązać bardzo prozaiczny problem. Mianowicie zauważyłem, że gdy ludzie mają w aplikacji niemal wyłącznie klasy, to mają silną tendencję do tworzenia ogromnych klocków, gdzie wszystko pospinane jest ze sobą, jak spaghetti. Ponadto sprawia to, że ludzie przestają patrzeć na to, co dany kawałek aplikacji powinien robić, tylko biorą jakąś rzecz i używają, "bo akurat im tu pasuje".

Zacząłem wprowadzać interfejsy dla pojedynczych serwisów, aby programiści nauczyli się myśleć w kategoriach "kontraktów" i tego, by nie przywiązywać się aż tak bardzo do tego, co jest po drugiej stronie. Jeśli chcesz sobie podejrzeć jakąś metodę, a zamiast tego trafiasz na interfejs z paroma metodami i musisz włożyć więcej wysiłku by znaleźć ich implementację, to zmusza to do pewnej refleksji. Ponadto w interfejsie widać głównie prototypy metod (no... od Javy 8 już niekoniecznie) i łatwiej jest dostrzec kontekst. Okazało się, że takie podejście zaczęło przynosić dobre efekty i dlatego je kontynuuję. Niejednokrotnie też później okazywało się, że te interfejsy przydawały się, gdy nagle okazywało się, że jednak jest potrzebna więcej niż jedna implementacja (albo gdy zaczynałem tworzyć nową implementację o statusie "eksperyment", która przez pewien czas funkcjonowała "na żądanie" równolegle ze starą). Jak widać, jest uzasadnienie dla takiego stylu programowania całkowicie niezależne od kontenerów, aspektów, itd. Chwalą to sobie zwłaszcza osoby nowe w projekcie, bo mogą wziąć sobie jakieś zadanie i skupić się na małym wycinku systemu.

Ktoś może zapytać czy tworzę też interfejsy dla jakichś utensyliów. Odpowiedź brzmi: nie, nie popadam tutaj ze skrajności w skrajność. Stosuję też bezpośrednie zależności między klasami, ale raczej na poziomie bardziej lokalnym, tj. kilka klas leżących obok siebie w jednym pakiecie, stosuję bezpośrednio klasy "utensyliowe".

@zyxist: kontrakty... no po to zostały interfejsy wymyślone :-) Tyle, że klasa to też kontrakt. Jak jest mała to go dobrze widać.

Różne są wypadki, też mi się zdarza zrobić interfejs do jednej klasy... ale to raczej wyjątek.
Jak dla mnie jak jest potrzeba drugiej implementacji - to wydzielenie metod do interfejsu to nie jest problem. Extract interface i posprzątane.

Interfejsy na zapas - jesli jest ich dużo, albo są niejako standardem (tak wszystko piszemy bo dziadowie kazali) to IMO smród.
Dodatkowo ten argument z zastanowieniem się, bo trafiamy na interfejs tak sobie działa:
Ctrl + Alt + B i jesteśmy w implementacji - nawet nie wiem, że po drodze był interfejs (ja tak sobie radze z przesadzonymi springowymi kobyłami).
Dodatkowo IntelliJ bezproblemowo uzupełnia i zmienia te wszystkie metody w interfejsie. .... więc wychodzi na to, że go mam, ale do niego nie zaglądam nawet -> ergo szum informacyjny.
Tu mówię o klasycznym przykładzie (mam taki teraz jeden soft), gdzie do każdego beana są pododawane interfejsy. Tylko mnie to wkurza - nic nie wnosi.

Btw. kiepscy programiści pewnie nie wszyscy potrafią skoczyć do implementacji od razu - więc rozumiem, że częściowo system działa. Potykają się o ten interfejs to ich spowalnia, piszą mniej kiepskiego kodu -> profit.

Argument "robię coś, bo ktoś mi kazał" jest smrodkiem. Natomiast argument "jak czegoś jest dużo, to jest to smród" można odnieść równie dobrze do programowania funkcyjnego i wszystkiego :), jeśli pozbawiony jest kontekstu. Ja patrzę na to tak:

jeśli stosuję coś w dużych ilościach z powodów takich, jak:

• ktoś mi kazał,
• bo to jest trendy,
• bez refleksji nad dostępnymi rozwiązaniami,
• by obchodzić jakieś ograniczenia technologii, którą używam,
  to jest to smród.

Natomiast co do reszty, to są różne style programowania. W kwestii kontraktów Twoje podejście ma również zalety i wady, ale nie jest jedynym słusznym. U mnie stosowanie interfejsów przynosi wymierne korzyści w postaci podniesienia jakości kodu. Nie posługuję się też generalizacjami "kiepscy programiści". Są ludzie, którzy są kiepscy, ale tak samo są ludzie, którzy dopiero zdobywają doświadczenie. Każdy był kiedyś początkujący, również Ty :). Ponadto widzę też, że profil tego, co piszesz (aplikacje), różni się trochę od profilu tego, co ja piszę (rozszerzalne biblioteki/rozwiązania dla programistów). W aplikacji końcowej, rozwiązującej jeden, konkretny problem, jest jeden kontrakt. U mnie często jest ich trochę więcej: kontrakt dla użytkownika, kontrakt dla mnie, które mogą się różnić i nie chcę, by użytkownicy widzieli i uzależniali się od wszystkich kontraktów w moim kodzie, bo później są duże problemy z utrzymaniem i migracją na nową wersję.

zyxist napisał(a):

Natomiast co do reszty, to są różne style programowania. W kwestii kontraktów Twoje podejście ma również zalety i wady, ale nie jest jedynym słusznym. U mnie stosowanie interfejsów przynosi wymierne korzyści w postaci podniesienia jakości kodu. Nie posługuję się też generalizacjami "kiepscy programiści". Są ludzie, którzy są kiepscy, ale tak samo są ludzie, którzy dopiero zdobywają doświadczenie. Każdy był kiedyś początkujący, również Ty :). Ponadto widzę też, że profil tego, co piszesz (aplikacje), różni się trochę od profilu tego, co ja piszę (rozszerzalne biblioteki/rozwiązania dla programistów). W aplikacji końcowej, rozwiązującej jeden, konkretny

Co do bibliotek to się zgadzam, ba zdarza się, że nawet mam interfejsy bez implementacji (poza testami).
A zarzut, że byłem kiedyś początkujący jest całkiem nieuzasadniony :-)

Btw. są kiepscy programiści - to tacy co się nie uczą i nie chcą uczyć. Więc nie zdobywają doświadczenia, nawet jeśli przypadkiem coś tam umieją.

@jarekr000000: czemu polecasz tylko Javę? Większość ofert pracy to Spring/Java EE.