Getery i setery - kiedy i czy używać

Pisze sobie gierke (Java+LibGdx) i zastanawiam sie nad jedna rzecza: czy jest sens stosowac getery i setery do zmiennych bedacych typem prostym? Przy zalozeniu ze geter po prostu pobiera zmienna, a seter zapisuje, bez zadnych kombinacji.

W moim odczuciu zaciemnia to kod. I teraz pytanie jak to u Was wyglada i jakie macie do tego podejscie. Bo w moim odczuciu ma to sens tylko w duzych projektach, ew. gdy jest to wymuszone przez framework (np. JavaBeany stosujemy). Oczywiscie co innego gdy zachodza jakies operacje pod spodem.

Jeszcze pytanie na marginesie, czy nowa Java ma jakis sprytna alternatywe dla get/set, tak jak np. C# ?

Jeśli zrobisz sobie podział klas na klasy z logiką i prywatnym stanem oraz klasy z publicznymi danymi to nie będzie problemu, bo z użyciem Project Lombok nie będzie śmieciowego kodu w klasach z publicznymi danymi.

ja dla małych struktur jak czasem muszę jakąś przekazywać między np. metodami robię public final int costam; i tyle

Klasy niezmienne i problem sam się rozwiązuje.

W Javie masz klasę java.util.Properties, która być może rozwiązuje Twój bliżej nieokreślony problem.

Z getterami/setterami masz 2 możliwości:

• nie masz zupełnie pojęcia co robisz i łamiesz reguły, o których pewnie też nie masz pojęcia
• dokładnie wiesz co robisz

Samo dostarczenie settera/gettera dla pola klasy powinno mieć dobre uzasadnienie projektowe. W jakim celu inne klasy potrzebują dostępu do pól rozważanej klasy? (zakładam, że to są pola private/protected, bo dla publicznych zagadnienie nie ma sensu).

Potrafię sobie wyobrazić zastosowanie setterów w implementacji dependency injection, czy transporcie danych między warstwami aplikacji, ale używanie "na bogato" może (nie musi) świadczyć o złym projekcie rozwiązania.

Koziolek - a moglbys rozwinac? Mam np. klase: OilField, gdzie taka klasa zawiera nazwe, ilosc ropy do wypompowania, cene, wlasciciela, glebokosc na ktorej znajduje sie ropa + pare podobnych parametrow. Sila rzeczy niektore z tych elementow zmieniaja sie w trakcie gry.

yarel - znam properties, ale to zupelnie nie jest to o co mi chodzi.

Przykładowo (pseudojava):

// gdzieś w grze
OilField field = OilFieldRepository.byId(id); // tu zwracamy coś co jest niepodpięte do żadnego ORMa czy czegoś takiego. Po porostu snapshot 
// przychodzi informacja o wydobyciu
field  = field.drill(number);

i metoda drill:

public OilField drill(long number){
   return new OilField(this).decreaseNumberOfOil(number);
}

private OilField decreaseNumberOfOil(long number){
  this.mineSize -= number;
  return this;
}

Co tu się dzieje. w metodzie drill masz obsługę wydobycia. Zwraca ona nowy obiekt utworzony za pomocą konstruktora kopiującego. Po drodze jest jeszcze ustawiana nowa wartość, ale dzieje się to na poziomie dostępu prywatnego zatem efekt uboczny (zmiana stanu obiektu) nie wypływa poza funkcję. Wołający otrzymuje metodę otrzymuje nową migawkę obiektu (nowy obiekt technicznie rzecz biorąc). Co więcej można sobie skonstruować w ten sposób całe "programy", które będą odpowiednio modyfikować obiekt wyjściowy nie naruszając jego integralności. Jak coś się wywali po drodze to będzie zawsze można ponowić operację ponieważ znamy stan wyjściowy....

I tu widać jak java jest paskudna.

Get i set na polu jest rownowazny z byciem publicznym. Jakies beansy czy tam inne nalecialosci wymagaly takiej skladni, ale imo jest to tylko niepotrzebny boiler code. Jezeli nic na nas nie wymusza takiej skladni to nie ma co sie oszukiwac - zmienic na public lub lepiej zrefaktorowac klase tak by sie pozbyc takich pol.

Jak zawsze i ja spróbuję wrzucić 3 Kowalskie grosze.

W projekcie występują zarówno gołe pola, jak i takie wyliczane w locie.
Pytanie za sto punktów: kto ma się domyślać kiedy co jest co?

@spartanPAGE, znaczy się, że masz problem, bo jeżeli wyliczanie w locie jest robione przez setter to nazewnictwo leży.

Ugh. W takim razie przytaczam nieśmiertelne owijki API pisanego w C, gdzie jedyną opcją dostępu do danych struktur są funkcje

Tu chodzi o coś innego. Settery i gettery w swojej "gołej" formie tzn. metody bez dodatkowej logiki to takie debilne dziecko specyfikacji Java Beans, która stworzyła metody dostępowe by ukryć w nich logikę dla całego mechanizmu powiadamiania o zmianach. Miało to sens w np. aplikacjach Swingowych gdzie masz wzorzec obserwatora. Jeżeli nie masz tego wzorca to pisanie getterów i setterów nie ma technicznego uzasadnienia. ORMy wspierają zapis i odczyt przez pola. Przy obiektach niemutowalnych nie ma sensu tworzyć publicznych settrów, a gettery nic nie wnoszą.