Po co gettery i settery?

Po co w Javie są gettery i settery skoro zawsze są publiczne (nie widziałem innych) ? Prywatne pola i brak setterów przyda się do tworzenia immutable obiektów ale nie widziałem tego zbyt często. Inną sytuacją która przychodzi mi do głowy to walidacja w setterach choć też czytałem, że nie powinno się raczej walidować w setterach pojo. Może ktoś podać konkretne przykłady lub wyjaśnić po co rzeczywiście stosuje się gettery i settery? Zaczynam naukę javy i prywatne pola i publiczne gettery/settery przewijają się wszędzie.

Przecież gettery i settery nie są wbudowane i nieodzowne, sam dodajesz :-)

• Jak idziesz w anemiczne modele -> gttery/settery będą naturlane
• Jak masz inversion of control i dependency injection -> settery/gettery mogą być alternatywą dla wstrzykiwania via konstruktor (lub adnotacji - pewnie w zależności od implementacji kontenera IoC)
• Jak idziesz w OOD -> gettery/settery wątpliwe, będziesz raczej miał metody zmieniające stan obiektu i zwracające jakiś deskryptor zmiany/publikujące zdarzenie/komunikat

Temat wielokrotnie wałkowany. Getterow i setterów nie trzeba stosować. Po prostu tak się kiedyś kodowało - i niektórym tak zostało.

1. Konstruktor
2. Builder
   długo długo nic
3. Setter

Niemniej gettery/settery są często potrzebne przy jakichś automatycznych mapowaniach w stylu DOT DTO->json i odwrotnie.

Shalom napisał(a):

Niemniej gettery/settery są często potrzebne przy jakichś automatycznych mapowaniach w stylu DOT->json i odwrotnie.

Pewnie miałeś na myśli niesławne DTO.
I nie, nie sa potrzebne od dawna raczej. Jackson nie potrzebuje w żadną stronę

@jarekr000000: a to bez setterów i getterów nie trzeba jakiś adnotacji (hehehehehe) do Jacksona?

Może się mylę, ale wydaje mi się, że settery / gettery są po to, żeby w pewnym sensie oddzielić interfejs od implementacji? Dzięki temu kiedyś w przyszłości możesz zmienić to co się pod nimi kryje nie psując reszty programu - interfejs nadal pozostaje taki sam.

@arczinosek nie, od tego są interfejsy. Gettery/settery właśnie w tym przeszkadzają bo eksponują na zewnątrz szczegóły implementacyjne.

A co z polami sprzężonymi? Ustawienie jednego pola powinno powodować zmianę drugiego, wtedy setter jest konieczny.

Java notes for professionals

zobacz se rozdział 3 Getters and Setters

Zadziwiające, że do getterów i setterów nie stostuje się zasada YAGNI.

@jarekr000000 @Wibowit dziś dzięki Twitterowi: https://spring.io/blog/2018/09/17/introducing-spring-data-jdbc

 Customer customer = new Customer();
 customer.dob = LocalDate.of(1904, 5, 14);
 customer.firstName = "Albert";

Note that you don’t need getters or setters. It is perfectly okay to use them if you prefer to do so. Really, the only requirement is that the entity has a property annotated with Id

Jestem zszokowany normalnie :D :D :D

Gettery i settery mają tą przewagę nad bezpośrednim dostępem do pól (pomijając sensowność takiego dostępu), że są wywołaniami metod (LOL), co jest inaczej obsługiwane przez JVM i można np. napisać proxy albo aspekt.

Poza tym uważam, ze gettey i settery powinny zostać zniszczone.

Niedawno się zarejestrowałem i ciekawił mnie właśnie ten temat więc pozwolę sobie odkopać, żeby dodać pewien ciekawy przykład który usłyszałem kiedyś na jakimś rosyjskim spędzie developerskim.

Wyobraźmy sobie że przychodzimy do baru z zamiarem wypicia piwa. Normalnie wyciągnęlibyśmy pieniądze z kieszeni, przekazali je barmanowi oraz wypili piwo.
Natomiast w erze getterów i setterów - 'barman manager' wyciągnąłby nam pieniądze z kieszeni i piwo wlał do gardła.

Taki gwałt na obiekcie w postaci piwosza.

Wibowit napisał(a):

Zadziwiające, że do getterów i setterów nie stostuje się zasada YAGNI.

Najzabawniejsze jest to że o ojciec YAGNI pisał właśnie o geterach i seterach kiedy YAGNI się narodziło :)

You find that you need a getter for some instance variable. Fine, write it. Don’t write the setter because “we’re going to need it”. Don’t write getters for other instance variables because “we’re going to need them”.

The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code.

You’re not gonna need it!

You’re NOT gonna need it!, Apr 4, 1998