[krasnoludkolo]

#java #programowanie

[ppawel]

@krasnoludkolo:
- do pól - nie (poza jakimiś legacy code gdzie szkoda czasu na poprawianie tego)
- do metod to standard - nadużywany przy pokrywaniu testami ale często tak łatwiej niż zaplanować dobry kontrakt ( ͡° ͜ʖ ͡°)
- do klas - mało kto używa czegoś innego niż public a czasem warto dla zapewnienia enkapsulacji na poziomie całych klas/pakietów

[krasnoludkolo]

@ppawel według mnie bardzo warto na poziomie klas. Sam wywaliłem z template generowanych przez ide. Można wtedy pakiety traktować jak w pewnym sensie obiekty z wystawionym publicznym API i osoba która zagląda tu poraz pierwszy nie musi czytać wszystkiego a jedynie klasy publiczne (widzi czym może się bawić)

Niestety póki co przegrałem pierwsza bitwę w pracy o to :(

[Myzreal]

@krasnoludkolo: Kod używający package scope jest jednym z wyznaczników tego, że mam do czynienia z kimś o sporym doświadczeniu - a przynajmniej z kimś kto potrafi porządnie ułożyć kod, aby publiczne były tylko te rzeczy, które muszą być - a najlepiej tylko interfejsy ( ͡° ͜ʖ ͡°)

[E.....e]

@krasnoludkolo: Mówisz o Api, ale zapewne robicie jakiś serwis a nie biblioteki gdzie faktycznie trzeba mieć publiczne api a reszte implementacji ukryć. W przypadku serwisów to i tak uzytkownik nie ma wglądu w Twój kod tylko ma dostep do waszego wystawionego api

[krasnoludkolo]

@Ewentualnie jako API pakietu mam na myśli zbiór metod które reszta projektu może używać

[E.....e]

@krasnoludkolo: No wiem, tylko ze w ramach projektu to nie jest tak istotne bo jak dajesz komuś biblioteke i zacznie z czegoś korzystac to ludzie będą się srac jak nagle przestaniesz im to udostępniać, w przypadku jakiegoś serwisu to tylko grupa programistow ktorzy rozwijaja ten projekt maja do tego dostep i w kazdej chwili mogą sobie zmienić z package private na public. Ja wiem ze Intellij podkreśla public jak warn

[krasnoludkolo]

@Ewentualnie tylko czemu programiści w projekcie nie ufają sobie? ;) Często z jakichś powodów serwis (czy tam modul, jak zwał tak zwał) ma takie metody a nie inne, np żeby potem nie robić dzikich hacków i tworzyć kolejnych zależności. Owszem, z czasem wymaganie się zmieniają ale rozwiązanie żeby zmienić private na public nie brzmi elegancko

[E.....e]

@krasnoludkolo: Package private nie ma chronic Cie przed hakami Twoich kolegów z pracy, bo tak jak powiedziałem w każdej chwili mozna zmienić na public. Albo innymi słowy, robiąc klasę package private i tak nie zabezpieczysz sie przed hakami z ich strony

[ajentidzej]

@krasnoludkolo: oczywiście, tam gdzie się da. Jeśli jest np. jakaś funkcjonalność która musi korzystać z kilku dedykowanych pod nią klas, to te wszystkie klasy mają package-scope, a klasa która z nich korzysta jest publiczna i wystawia jedną metodę :)
https://www.youtube.com/watch?v=KO6K3_Ac54M&t=2s
Bardzo fajny wykład na ten temat, miałem przyjemność słuchać na żywo. Daje do myślenia.
Jeszcze prezentacja z tego wykładu: https://jakubn.gitlab.io/keepitclean/#1

[kot_gagarina]

@krasnoludkolo: Dokładnie tak jak piszesz. Tylko trzeba dodać że programista nie może być egoistą i zawłaszczyć wszystko dla siebie - no bo kto się zna lepiej niż on sam. Dobrą praktyką jest podzielenie problemu na fragmenty i wrzucenie tego w metody z kodem mieszczącym się na ekranie i wywoływanie ich z metody final. Jeżeli te metody nie namieszają w kodzie i może istnieć różnorodność implementacji to powinny być protected.

[krasnoludkolo]

@ajentidzej dzięki tej prezentacji od jakiegoś czasu zacząłem tak robić ;)

[krasnoludkolo]

@kot_gagarina ja się staram robić klasy mieszczące się na jednym ekranie a nie metody :0

[kot_gagarina]

@krasnoludkolo: Nie zawsze się da :-)

[krasnoludkolo]

@kot_gagarina powinno się dać ( ͡º ͜ʖ͡º)

[kot_gagarina]

@krasnoludkolo: A jak ktoś ma mały ekran (25 linii)? ¯\_(ツ)_/¯