Java, jako język w pełni obiektowy oferuje nam wszystkie aspekty tego paradygmatu programowania. Zauważyłem, że wiele osób początkujących szczególnie może mieć kłopoty z poprawnymi referencjami do obiektów w polach klas i tworzeniem właśnie tych klas. Dziś przedstawię Ci jedno rozwiązanie, które zdecydowanie ułatwi Ci życie. 

Gdy uczymy się programowania obiektowego oczywiście wszyscy stosujemy w pewnym momencie “settery” i “gettery” generowane przez IDE lub później Lomboka i jego adnotacje “@Getter”, “@Setter” albo po prostu “@Data”. Daje nam to duże ułatwienie. Jednak czy warto poświęcić kontrolę nad naszą klasą na rzecz paru linijek kodu? 

‍

Tutaj pojawia się pewne słówko-klucz, które o dziwo jest bardzo mało znane nawet juniorom Javy, a mowa o  “final”. Jest to swego rodzaju game-changer, ponieważ mówi nam to, że całe podejście z setterami w znakomitej większości nie ma sensu. Moim zdaniem prawidłowo, poniewaz dzięki temu mamy kontrolę nad naszymi obiektami, które jak się okazuje nie muszą mieć setterów jeżeli nie są to obiekty przenoszące lub reprezentujące jakieś struktury danych ;) Wymusza to na nas pewne podejście, które tak naprawdę ratuje nam aplikację, ale nie każdy o tym wie.

‍

Weźmy sobie taki przykład:

‍

W sytuacji rozrostu tej klasy trzeba wywoływać setter co każdą zależność 🤯

Wciąż najważniejszym problem jest to, że tracimy kontrolę nad referencjami w tej klasie, ponieważ każdy może sobie je zmieniać tak długo jak będą współdzielić interfejs. W efekcie może to mieć destrukcyjny wpływ na naszą aplikację. Dodatkowo, warto mieć na uwadze, że taka podmiana referencji może się dziać nie tylko przez setter, lecz także przez getter. Czyli w tej klasie mamy 2 metody, które mogą nam zniszczyć całą aplikacje.

‍

Co w takiej sytuacji należy zrobić?

‍

Rozwiązanie jest bardzo proste. Możemy dodać jeden modyfikator “final”. Wtedy kod wygląda następująco:

‍

lub możecie wykorzystać Lomboka

‍

‍

Widać gołym okiem, że teraz nasz kod jest w o wiele lepszej kondycji. Dodatkowo pozbyliśmy się niepotrzebnego gettera. Dla klas, które nie przekazują danych tylko wykonują logikę biznesową w znakomitej większości nie ma potrzeby upubliczniania pól.

‍

Porada ode mnie na koniec  - naprawdę dobrze zapoznajcie się z zasadami OOP. Szczególnie, warto znać rodzaje konstruktorów w Javie, bo to właśnie one zapewniają nam kontrolę nad naszymi klasami.

‍