Prośba o ocenę stronki w javie od zielonego

Yo.
Od pewnego czasu postanowiłem, w wolnym czasie, nauczyć się programować w javie.

Jako, że jestem zielony prosiłbym o ewentualne wskazówki,
porady lub nawet i linki do waszych repozytoriów dzięki którym mógłbym podszkolić swoje umiejętności.

Dodatkowo proszę o rzucenie okiem na moją aplikację, jestem pewny,
że znajdzie się tam kilka rzeczy do poprawienia. Aplikacja ma robić za małą, domową bibliotekę.
https://github.com/karol911212/HomeLibrary

							                                            Z góry dzięki :p

popraw link

pozdro napisał(a):

popraw link

zrobione :p

Możesz startować na juniora z taką apką, tylko olej servlety i inne kotlety. Przerób to na RESTa, zrób prosty froncik w jakimś reactie/vue i szukaj pracy.

No i możesz podpiąć pod to jakieś CI/CD np CircleCI.

Szczery Karp napisał(a):

Możesz startować na juniora z taką apką, tylko olej servlety i inne kotlety. Przerób to na RESTa, zrób prosty froncik w jakimś reactie/vue i szukaj pracy.

No i możesz podpiąć pod to jakieś CI/CD np CircleCI.

Okej, to już coś. W kolejnym kroku dodam RESTa i zabiorę się za poznawanie spring security. Dzięki

Skąd ta mania w ludziach żeby nazwy interfejsów zaczynać od I?Np. ISingleBookAdministratorService
A implementacje nazywają się normalnie. Przecież jakby się tak zastanowić to klas implementujących te interfejsy mając DI nie używasz w kodzie. Korzystasz tylko z interfejsów jako kontraktu a implementacja jest wstrzyknięta. Znacznie lepszym rozwiązaniem jest nazywanie interfejsów normalnie bez żadnych sufixów i prefixów a do implementacji dodać np. Impl na koniec.

W klasie BindingResultErrors (i nie tylko) sprawdzasz czy result nie jest nullem albo pusty itp. Proponuje zrobić jeden warunek i skorzystać np. z isBlank . Nie jest to oczywiście żaden błąd ale moim zdaniem ta metoda jest czytelniejsza, obsługuje więcej przypadków i redukuje niepotrzebny kod.

W bardzo wielu klasach zauwazyłem że pola mają dostęp default'owy. to celowe? Jak dla mnie to wszedzie powinno być prywatne.

Takie kody:

new ArrayList<String>().add("sprawdŸ czy poda³eœ odpowiednie dane")

Możesz zamienić np. na:

Arrays.asList("sprawdŸ czy poda³eœ odpowiednie dane")

	@ManyToMany(fetch = FetchType.EAGER)
	@Column(nullable=false)
	private List<AuthorModel> authors;

Proponuję zdebugować aplikację i zobaczyć jaki muł zasysasz robiąc zapytanie np. o Książki :P

W wolnej chwili jeszcze popatrzę ale ogólnie jak na początek to moim zdaniem jest okej, trochę rzeczy do poprawy ale na juniora możesz próbować ;)

eL napisał(a):

Skąd ta mania w ludziach żeby nazwy interfejsów zaczynać od I?Np. ISingleBookAdministratorService

W C# są interfejsy biblioteki standardowej używające tej konwencji (np. IEnumerable<T>)

W C# tego co pamiętam (dawno w nim nie pisałem) implementacja interfejsów i dziedziczenie realizowane są przez ten sam, nazwijmy to "operator". Czyli znak dwukropka. Kiedy patrzysz na klasę i patrzysz na to co dziedziczy i implementuje, nie mając kolorowania składni, możesz nie do końca widzieć co jest interfejsem, a co klasą. Stąd chyba ta notacja z wiodącym "I".

Wątek jest o Javie, w której to ta notacja nie ma sensu (moim zdaniem jest zwyczajnie nadmiarowa), aczkolwiek są ludzie którzy mogli być do tego przyzwyczajeni i jest im wygodnie w ten sposób nazywać rzeczy. ;)

S-cat napisał(a):

eL napisał(a):

Skąd ta mania w ludziach żeby nazwy interfejsów zaczynać od I?Np. ISingleBookAdministratorService

W C# są interfejsy biblioteki standardowej używające tej konwencji (np. IEnumerable<T>)

W C# tego co pamiętam (dawno w nim nie pisałem) implementacja interfejsów i dziedziczenie realizowane są przez ten sam, nazwijmy to "operator". Czyli znak dwukropka. Kiedy patrzysz na klasę i patrzysz na to co dziedziczy i implementuje, nie mając kolorowania składni, możesz nie do końca widzieć co jest interfejsem, a co klasą. Stąd chyba ta notacja z wiodącym "I".

Wątek jest o Javie, w której to ta notacja nie ma sensu (moim zdaniem jest zwyczajnie nadmiarowa), aczkolwiek są ludzie którzy mogli być do tego przyzwyczajeni i jest im wygodnie w ten sposób nazywać rzeczy. ;)

Moje I nabyłem przeglądając kod innych, uznałem to za sposób na bardziej opisowy kod(chociaż faktycznie mało to zmienia)

Co do testów:

• Powinno się unikać randomowych Stringów ale wiadomo, nie zawsze się da. Natomiast nazwanie metody

splitAuthorsWhereSurnameEqualsKotekPiesMisiuTest()

to już przesada xD

• Bardzo dużo mocków. Możesz na potrzeby testów stworzyć jakąś in-memory implementacje bazy.

baant napisał(a):

Co do testów:

• Powinno się unikać randomowych Stringów ale wiadomo, nie zawsze się da. Natomiast nazwanie metody

Kopiuj

splitAuthorsWhereSurnameEqualsKotekPiesMisiuTest()

to już przesada xD

• Bardzo dużo mocków. Możesz na potrzeby testów stworzyć jakąś in-memory implementacje bazy.

Jestem konsekwentnym człowiekiem ! Ale nie ukrywam, że masz rację :p
Masz link do jakiegoś gita żebym mógł lepiej zrozumieć sprawę(masz na myśli h2 czy jakąś listę statyczną)?

1. Po te interfejsy z jedną implentacją?
   2.Wrzucanie eclipsowego workspace nie jest najlepszym pomysłem. Wrzuć projekt a eclipsowe badziewie daj do gitignore
   3.To dziedziczenie po klasie model też jest słabe. Klasa np. user powinna mieć userId a nie id jako pole.
   4.Użyj lomboka
   5.Package w katalogu test powinien być taki sam jak w mainie.
   Tzn.
   com.superapp.service.SuperServiceTest odpowiada na com.superapp.service.SuperService
   6.Zainstaluj sobie normalne IDE (IntelliJ) zamiast eclipsa
   7.Polecam korzystac z VAVRa

@scibi92

Lombok is an annotation processor (a compiler plugin, if you want). At compile time, it gets called each time a particular set of annotations is found in your code, and is given the opportunity to generate new sources or throw compiler errors. If anything new is generated during a compilation round, another one must take place, until all has been successfully compiled. So yes, it takes time to find the annotations, process them as required (see below), and to run the extra compilation rounds.
The Annotation processor specification explicitely forbids them to modify existing code - you can produce new classes or extra files (.properties, etc), but not change the existing code. Lombok goes around that by detecting the compiler used, and hacking its internal APIs to change the AST in-memory to add accessors and such. This is just... terrible.
And this is, in my opinion, a major technological risk. In the end, Lombok does nothing your IDE can't do - generate accessors, etc., but could endanger your whole project - what if you upgrade your compiler and Lombok does not support it, or introduces a bug ? You end up with a non-compiling code (or in your case, a very slow compilation), only to hide some boilerplate methods that do no harm except take a few lines in your code. But that's just my opinion :)
So to come back to your problem, I don't see how you could get better compilation times, except by removing Lombok alltogether.

yo

#1 Eclipsowy workspace poprawiony(scibi92).
#2 Package w katalogu test poprawiony(scibi92).
#3 Arrays.asList poprawione, jest o wiele krótsze(eL).
#4 isBlank z apache commons jest świetne, szkoda ,że nie natknąłem się na niego wcześniej(eL).
#5 z tą enkapsulacją dałem ciała, kiedyś coś tam testowałem przez co nie rzuciło mi się w oczy(eL).
#6 @ManyToMany(fetch = FetchType.EAGER) zmieniłem na lazy, podglądam zapytania do i z bazy danych lecz nie widzę różnicy(swoją drogą czy @manyToMany domyślnie nie jest EAGER?). Źle zabrałem się do sprawy(eL)?
#7 poprawiłem nazwy interfejsów(eL).

rozgraniczanie w ten sposób zadań i poziomu dostępu do danych (przez interfejsy nawet z jedną metodą) jest nieprawidłowe(scibi92) ?

W Jpa domyślne jest tak:
Many to one - EAGER
One to one - EAGER
Many to many - LAZY
One to many - LAZY

Polecam domyślnie korzystać z lazy. dlaczego? Ponieważ założmy że mamy taką sytuację - potrzebujmy tylko kilka danych na temat przedmiotu więc wysyłamy zapytanie do bazy danych o klasę Product. Załóżmy że klasa product jest poważana z klasą Discount, Category, Brand, ProductAdvertisement itd.
Jeżeli wszędzie masz ustawione EAGER a potrzebujesz pobrać tylko klasę Product podczas jednek transakcji pobierzesz dodatkowo wszystkie inne klasy. Tak więc zamiast wysłać jedno zapytanie do bazy danych wyślesz tych zapytań kilka. Mało tego, załóżmy, że np klasa Brand reprezentująca markę produktu zawiera inne relacje z klasami np: BrandAddress, BrandOpinions, BrandRatings itd. Jeżeli wszędzie masz ustawione EAGER wysyłasz kolejne bezsensowne zapytania.
A ty przecież chciałeś tylko pobrać jedną klasę o nazwie Product, a wysłałeś w tym momencie 20 zapytań do bazy danych.

• raz że cierpi na tym wydajność, bo zrobiłeś 20 zapytań zamiast jednego
• dwa - cierpi na tym pamięć, bo pobrałeś nieistotne dla aplikacji dane, które zajmują miejsce w pamięci.

Dlatego domyślnie wszędzie ustawiaj Lazy, a jeżeli chcesz koniecznie pobierać kilka rzeczy naraz to zrób sobie specjalne zapytania, możesz też użyć

JOIN FETCH

możesz użyć adnotacji

@NamedEntityGraph oraz @EntityGraph

która załaduje ci daną relacje typu OneToMany albo ManyToMany na życzenie.

albundy napisał(a):

W Jpa domyślne jest tak:
Many to one - EAGER
One to one - EAGER
Many to many - LAZY
One to many - LAZY

Polecam domyślnie korzystać z lazy. dlaczego? Ponieważ założmy że mamy taką sytuację - potrzebujmy tylko kilka danych na temat przedmiotu więc wysyłamy zapytanie do bazy danych o klasę Product. Załóżmy że klasa product jest poważana z klasą Discount, Category, Brand, ProductAdvertisement itd.
Jeżeli wszędzie masz ustawione EAGER a potrzebujesz pobrać tylko klasę Product podczas jednek transakcji pobierzesz dodatkowo wszystkie inne klasy. Tak więc zamiast wysłać jedno zapytanie do bazy danych wyślesz tych zapytań kilka. Mało tego, załóżmy, że np klasa Brand reprezentująca markę produktu zawiera inne relacje z klasami np: BrandAddress, BrandOpinions, BrandRatings itd. Jeżeli wszędzie masz ustawione EAGER wysyłasz kolejne bezsensowne zapytania.
A ty przecież chciałeś tylko pobrać jedną klasę o nazwie Product, a wysłałeś w tym momencie 20 zapytań do bazy danych.

• raz że cierpi na tym wydajność, bo zrobiłeś 20 zapytań zamiast jednego
• dwa - cierpi na tym pamięć, bo pobrałeś nieistotne dla aplikacji dane, które zajmują miejsce w pamięci.

Dlatego domyślnie wszędzie ustawiaj Lazy, a jeżeli chcesz koniecznie pobierać kilka rzeczy naraz to zrób sobie specjalne zapytania, możesz też użyć

Kopiuj

JOIN FETCH

możesz użyć adnotacji

Kopiuj

@NamedEntityGraph oraz @EntityGraph

która załaduje ci daną relacje typu OneToMany albo ManyToMany na życzenie.

dzięki za cierpliwe wyjaśnienie, na bank zapamiętam :D

@filemoon: przejęzyczyłem się, chodziło mi o interfejsy z jedna implementacją. Czasem moga miec sens (jak np. piszesz swoją bibliotekę która będziesz udostępniał innym) ale w takiej logice biznesowej to overkill. Niestety to cos co sam długo robiłem... (jak to @jarekr000000 mówi "Kult Cargo" )

scibi92 napisał(a):

@filemoon: przejęzyczyłem się, chodziło mi o interfejsy z jedna implementacją. Czasem moga miec sens (jak np. piszesz swoją bibliotekę która będziesz udostępniał innym) ale w takiej logice biznesowej to overkill. Niestety to cos co sam długo robiłem... (jak to @jarekr000000 mówi "Kult Cargo" )

uznałem, że aplikacja może się rozrosnąć i postanowiłem się zabezpieczyć :p. W dużym projekcie to faktycznie może być problem

Od razu mam pytanie. Warto się uczyć frontu czy dalej rozwijać backend? Jeśli tak to czy brać się za wyżej wymieniony reactive, vue, angular czy może polecacie coś innego ?

Jeżeli dobrze pamiętam to w Repository możesz zwracać Optionale

filemoon napisał(a):

scibi92 napisał(a):

@filemoon: przejęzyczyłem się, chodziło mi o interfejsy z jedna implementacją. Czasem moga miec sens (jak np. piszesz swoją bibliotekę która będziesz udostępniał innym) ale w takiej logice biznesowej to overkill. Niestety to cos co sam długo robiłem... (jak to @jarekr000000 mówi "Kult Cargo" )

uznałem, że aplikacja może się rozrosnąć i postanowiłem się zabezpieczyć :p. W dużym projekcie to faktycznie może być problem

A w jaki sposób Cię to zabezpiecza? Ja rozumiem jakby bp. było to jakieś DAO/Repository bo będziesz chciał przepiąc sie z JPA na JDCB ale serwisy?

Czesc.
Z czystej ciekawosci od jakiego czasu uczysz sie Javy? Ile dziennie nauce poswiecales?