Do czego służą gettery i settery?

0

Cześć, czy ktoś mógłby mi na jakimś obrazowym przykładzie wytłumaczyć konkretnie do czego służą gettery i settery?

4

Gettery i settery służą do:

  • pobierania danych z obiektu (get),
  • zapisywania danych w obiekcie (set)
    przy jednoczesnym zachowaniu hermetyzacji.

Zasadniczo 90% przypadków wykorzystania getterów i setterów to tzw. data classes bądź POJOs, czyli klasy nierobiące nic poza przechowywaniem zmiennych. W takich wypadkach używanie akcesorów mija się z celem, lepiej po prostu zrobić publiczne pola. Korzystanie z getterów i setterów pozwala na zachowanie uniform data access - dostępu do danych w taki sposób, że nie wiemy, czy są one już zapisane w obiekcie, czy są obliczane na podstawie innych danych.

Na przykład wyobraźmy sobie klasę Vector2D (celowo bez implementacji):

class Vector2D {
    public double getX();
    public void setX(double x);

    public double getY();
    public void setY(double y);

    public double getAngle() ;
    public void setAngle(double x);

    public double getLength();
    public void setLength(double length);
}

Korzystając z takiej klasy nie wiesz, czy wewnętrznie przechowuje współrzędne x i y, czy może angle i length. Nie ma to jednak znaczenia, gdyż korzystasz z getterów i setterów, a nie z publicznych zmiennych.

3

używanie akcesorów mija się z celem, lepiej po prostu zrobić publiczne pola

Korzyścią z korzystania z setterów nad publicznymi polami jest to, że czasem przy okazji zapisania/odczytania jakiejś wartości, może być potrzeba wykonania dodatkowych operacji. Przykładowo - zapisanie do logu poprzedniej wartości albo daty modyfikacji, ponowne narysowanie napisu w chwili zmiany wielkości czcionki czy koloru albo sprawdzanie wprowadzonej wartości. Jeśli masz po prostu publicznie dostępną wartość (np. wagę obiektu) to umożliwiając do niej zapis, nie zabezpieczysz się przed przypisaniem koleżance wagi -350kg. Ale korzystając z settera możesz wychwycić pewien rodzaj błędów i odpowiednio zareagować. Tak samo, getter może nie tylko zwracać wartość konkretnej zmiennej, ale może wykonać pewne operacje - analogicznie do JOIN w SQL, który zwraca tabelę, która realnie w bazie nie istnieje i wynika z połączenia kilku tabel.

4

Można też ustawić właściwość tylko do odczytu przy pomocy {get;private set;}

3

Język programowania nie został podany, więc napiszę ogólnie, nawiązując do używanej przeze mnie technologii.


Ideą i głównym powodem istnienia getterów i setterów (lub jak kto woli: akcesorów i mutatorów lub metod dostępowych i zmieniających) jest możliwość wykonania operacji dodatkowych i określania poziomu dostępu do danych. Owe dodatkowe operacje można podzielić na kilka kategorii.

1. Określanie sposobu dostępu

Nie wszystkie dane zawarte w obiektach służą do odczytu i zapisu – wiele służy wyłącznie do odczytu, a niektóre wyłącznie do zapisu (choć takie można spotkać bardzo rzadko). Gdyby nie settery i gettery, nie było by możliwości określania dostępu.

2. Operacje dodatkowe

Oprócz zwrócenia danych pobranych z konkretnego pola np. klasy, wykonuje się inne dodatkowe czynności. Tu przykład podał @cerrato – oprócz zwrócenia czy modyfikacji danych, dodatkowo można logować informacje. Jeśli o settery chodzi, to zmiana jednej wartości w klasie może powodować konieczność aktualizacji wielu innych.

Taka potrzeba zachodzi praktycznie we wszystkich klasach komponentów (wizualnych i tych niewizualnych). Dla przykładu, ustalamy nową szerokość kontrolki za pomocą właściwość Width, co oznacza modyfikację obszaru kontrolki, ale także dodatkowo m.in. aktualizację jego pozycji (według wyrównania i kotwic), rozmieszczenia kontrolek osadzonych, przemalowania interfejsu i wielu, wielu innych rzeczy.

Przykładem dla getterów może być zwykły bufor cykliczny – pobranie wartości z bufora wymusza automatyczne przesunięcie wskaźnika na bieżącą komórkę/węzeł, co może być realizowane właśnie w getterze. Gdyby go nie było, to po każdorazowym odczycie danych, trzeba by samemu aktualizować ten wskaźnik, co tylko wydłużałoby kod i zwiększało szanse na błędy.

3. Walidacja danych

Wiele klas posiada właściwości pozwalające na przeglądanie swojej zawartości. Dla przykładu, dana klasa może posiadać w sobie kolekcję (listę) ciągów znaków i pozwalać pobierać te konkretne na podstawie indeksu. Aby móc zareagować na podanie nieprawidłowego indeksu (spoza zakresu listy), getter najpierw go waliduje i rzuca wyjątek, jeśli ten jest nieprawidłowy.

W ten sposób gettery i settery stają się praktycznie jedyną formą tworzenia zabezpieczeń, które nie pozwalają na zdestabilizowanie obiektu, ale też pozwalają programiście łatwo zlokalizować ewentualne błędy w swoim kodzie.

4. Przygotowanie danych

Nie wszystkie dane zwracane przez gettery leżą grzecznie w polach – niektóre z nich trzeba najpierw przygotować, zanim się je zwróci. Tutaj przykład znów podał @cerrato – danych nie ma w polach, trzeba je najpierw skądś pobrać (np. z bazy danych, pliku, strumienia itd.), ale też mogą być na bieżąco obliczane, na podstawie tych zawartych w polach.

Dla przykładu, dana klasa zawiera współrzędne wierzchołków prostokątnego obszaru. Aby określić wysokość i szerokość tego obszaru, trzeba by odczytać wartości wszystkich tych wierzchołków i sobie policzyć wymiary. Ale można też stworzyć właściwości AreaWidth i AreaHeight, które w swoich getterach wykonują takie obliczenia i zwracają interesujące nas dane.


To tylko te najważniejsze, a raczej pierwsze, jakie przyszły mi do głowy. Oczywiście do tego dochodzi wiele innych możliwości, np. związanych z dziedziczeniem, kiedy to akcesor i/lub mutator może być metodą wirualną (a nawet abstrakcyjną). Ale o tym może kiedy indziej – co za dużo to niezdrowo. ;)

3

Do udawania że mamy jakąkolwiek enkapsulację i kontrolę nad stanem naszych obiektów bez konieczności faktycznego projektowania obiektowego

0
  1. Metody, a więc gettery i settery też, mogą być virtualne i reimplementowane w klasach dziedziczących, gdy dane (pola) nie są dziedziczone. To ma znaczenie w bibliotekach i frameworkach do Dependency Injection czy Object Persistence (na gruncie Javy JPA). Nie jest to kod ludzki rękami czyniony, tylko "pod spodem" przez bibliotekę. W/w biblioteki mogą stosować swoje działanie do pól, ale mają uboższy zakres funkcjonalny
0

Mimo wszystko przydałoby się wspomnieć o jaki konkretnie język programowania chodzi. W końcu każdy jest inny, a właściwość właściwości nierówna. W niektórych językach właściwości wcale nie muszą być częściami klas – mogą dotyczyć mniej zaawansowanych ”kontenerów”, takich jak struktury czy typy proste, albo nawet istnieć jako zupełnie osobne twory.

0

IMO na ogół nie mają za bardzo sensów. Zazwyczaj stosuje się je w DTOsach które nie sa prawdzimi obiektami tylko pojemniczkami na dane. Dobre podejście jest w Groovym czy Kotlinie gdzie DTOsy kompilują się do bajtkodu Javovego i z punktu widzenia Javy niby je masz, ale w kodzie operujesz po polach, a gdyby coś sie naprawde stało i rzeczywiście potrzebował tych setterow/getterów to łatwo dodac, jest to nawet lepiej zrobione niż w tym cudownym i nowoczesnym C#. A najlepiej robić niemutowalne obiekty DTO i dawać wszystko przez konstruktor.

0
scibi92 napisał(a):

IMO na ogół nie mają za bardzo sensów. Zazwyczaj stosuje się je w DTOsach które nie sa prawdzimi obiektami tylko pojemniczkami na dane

Tutaj pozwolę się nie zgodzić. Podany przez @furious programming przykład (który też mi chodził po głowie i częściowo był inspiracją do wspomnienia o zmianie wielkości czcionki i koloru, ale z braku czasu aż tak obszernie i merytorycznie jak Furious tematu nie pociągnąłem), czyli środowisko RAD i komponenty pięknie pokazuje, że settery niekoniecznie muszą być stosowane jako składniki pojemników na dane. W przypadku środowisk RAD (aczkolwiek oczywiście nie tylko) wszystko jest obiektem - okno (znaczy - formatka), komponenty wizualne i niewidoczne. I wszystkie bardzo mocno korzystają z mechanizmów setter'ów - chociażby jak pisał Furious, zmieniając Form1.Width := 450 tak na prawdę nie zmieniasz wartości jakiejś zmiennej, ale wykonywany jest cały łańcuch działań.

A poza tym to nie widzę niczego złego w tworzeniu pojemników :P Oczywiście, z prawdziwym OOP nie ma to bardzo dużo wspólnego, ale nie jest niczym złym. Zwłaszcza, jeśli się przy okazji wprowadza jakąś formę walidacji danych wejściowych.

3

gettery to funkcje, które się odpalają jak chcesz pobrać właściwość z obiektu.
settery to funkcje, które się odpalają jak zapisać właściwość z obiektu.
w niektórych językach można zrobić w ten sposób "przezroczyste właściwości", tj.

foo.bar; // odpali się getter dla bar
foo.bar = 123; // odpali się setter dla bar z podanym argumentem 123

w niektórych językach nie ma takiej opcji i to, co można zrobić to najwyżej funkcje getFoo oraz setFoo (nie wiem co jest lepsze - z jednej strony właściwości pozwalają na ładniejszy zapis, z drugiej strony funkcję pozwalają na większą przejrzystość, bo nie ma magii pod spodem, tylko od razu jesteś w stanie stwierdzić, czy dany obiekt korzysta z getterów/setterów czy nie).

Do czego się przydają? Gettery - jeśli chcesz udostępnić jakieś dane z obiektu w sposób, który pozwoli ci na kontrolę nad tym jak to udostępniasz. Settery - jeśli chces pozwolić na zapisywanie danych do obiektu, które pozwolą ci na kontrolę/walidację itp. tych danych.

Innymi słowy złamanie zasady enkapsulacji ale w sposób kontrolowany. Pisząc w paradygmacie obiektowym raczej będziesz starał się unikać pisania getterów i setterów, ponieważ w ten sposób za dużo osłonisz i nie będzie różniło się to wiele od tego jakbyś zrobił wszystkie właściwości obiektu publiczne.

Ale czasem się przydają. Np. niedawno zrobiłem klasę kolekcji w swojej bibliotece i tam użyłem gettera count, które zwraca liczbę elementów w kolekcji.
Moja klasa kolekcji opiera się na tablicy, więc w tej chwili ten getter po prostu zwraca długość tablicy.

    get count() {
        return this._data.length;
    }

Ale po co się tak bawić? Czy nie lepiej byłoby po prostu udostępnić tablicę jako publiczną? Wtedy każdy nie dość, że mógłby sobie odczytać długość collection.data.length to mógłby użyć metod tablicowych takich jak map czy filter?

No nie, bo:

  1. to by odsłoniło za dużo i ktoś z zewnątrz mógłby np. skasować zawartość tablicy
  2. w przyszłych implementacjach mógłbym chcieć w ogóle zrezygnować z tablic na rzecz jakichś bardziej wydajnych struktur danych (b-trees czy coś takiego). Czyli w przyszłej implementacji tablic w ogóle może nie być, a będzie dalej getter count, który zwróci w jakiś inny sposób wielkość kolekcji.

I teraz tak - czy w ogóle jest sens udostępniać liczbę elementów? W tym przypadku tak, ponieważ robię klasę kolekcji, więc jako użytkownik tej klasy chciałbym móc odczytać liczbę elementów, bo może to być przydatne np. po to, żeby wyświetlić tę liczbę elementów na ekranie (np. lista produktów w koszyku: 10) (niestety wiele osób robi gettery i settery na zapas, nawet jeśli są totalnie niepotrzebne).

0
LukeJL napisał(a):

gettery to funkcje, które się odpalają jak chcesz pobrać właściwość z obiektu.
settery to funkcje, które się odpalają jak zapisać właściwość z obiektu.
w niektórych językach można zrobić w ten sposób "przezroczyste właściwości", tj.

foo.bar; // odpali się getter dla bar
foo.bar = 123; // odpali się setter dla bar z podanym argumentem 123

w niektórych językach nie ma takiej opcji i to, co można zrobić to najwyżej funkcje getFoo oraz setFoo (nie wiem co jest lepsze - z jednej strony właściwości pozwalają na ładniejszy zapis, z drugiej strony funkcję pozwalają na większą przejrzystość, bo nie ma magii pod spodem, tylko od razu jesteś w stanie stwierdzić, czy dany obiekt korzysta z getterów/setterów czy nie).

foo.bar = 123

Na pewnym etapie trzeba by mówić o właściwości (property). Java w swoim ekosystemie posiada koncepcję property (Bean by bez tego nie istniał), ale nie ma w syntaxie języka adekwatnej konstrukcji (dwie zwykłe funkcje jak ręcznie pisane, tylko konwencja). Biblioteki Javy za to masowo opierają się konwencji property - we wszelkich templejtkach pisze się foo.bar)
Inne języki JVM to naprawiają

Więc pakiet koncepcji o jakich mówimy (chyba we wszystkich językach obiektowych) to pole, para getter/setter (nie zawsze akurat para), i właściwość

2
kamillapinski napisał(a):

Gettery i settery służą do:

  • pobierania danych z obiektu (get),
  • zapisywania danych w obiekcie (set)
    przy jednoczesnym zachowaniu hermetyzacji.

Zasadniczo 90% przypadków wykorzystania getterów i setterów to tzw. data classes bądź POJOs, czyli klasy nierobiące nic poza przechowywaniem zmiennych. W takich wypadkach używanie akcesorów mija się z celem, lepiej po prostu zrobić publiczne pola. Korzystanie z getterów i setterów pozwala na zachowanie uniform data access - dostępu do danych w taki sposób, że nie wiemy, czy są one już zapisane w obiekcie, czy są obliczane na podstawie innych danych.

Należysz do jakiegoś klubu złych praktyk programowania?

2

Ale co dokładnie jest złą praktyką? Unikanie getterów i setterów, kiedy nic nie robią, czy może uniform data access, który pozwala ukryć szczegóły implementacji?

Unikanie getterow i setterow, a mówiąc dokładnie to unikanie ich dla tego ze AKTUALNIE nic nie robią. Pomijając kwestie możliwych zmian w przyszłości to używanie G/S tylko wtedy kiedy potrzebna jest jakaś dodatkowa logika wprowadza jedną chaotyczną rzecz do kodu- niekonsekwencje.

0

A mnie zastanawia po co w c# stosuje się puste gettery i setery, czyli puste get i set?

1
kulson napisał(a):

A mnie zastanawia po co w c# stosuje się puste gettery i setery, czyli puste get i set?

W siszarpie property ma bardzo mocno ugruntowaną pozycję. W olbrzymiej większości API bibliotek szanowana jest tylko właściwość, pole choćby publiczne to już nie.
Taka para type Nazwa { get; set; } już tworzy najprostszą property ... już jest nią a nie polem.

Na debugerze można zobaczyć, że te dwie get_NAzwa i set_Nazwa są wygenerowane.

0

Co to znaczy, "szanowana jest tylko właściwość"? Dalej nie wiem, co to zmienia. Skoro odwolujesz się tak samo, jak do pola publicznego, a getter i setter są puste.

Chętnie bym zobaczył przykład, który nie skompiluje się po zamianie pustego get set na pole publiczne

0

@Aventus:
1)Ile razy musiałes robić inną implementace setterów i getterów?
2)Nie musisz stosować setterow jesli tworzysz niemutowalny obiekt
No i tyle w temacie, handluj z tym
@cerrato oczywiście, ale tutaj zakładalem że mówimy o typowych setterach i getterach w klasach typu POJO. Co innego jakies widgety i tego typu rzeczy :)

0

@scibi92:

  1. Wiele, bardzo wiele. I nie widzę w tym nic niezwykłego. Wymagania się zmieniają, logika się zmienia. Naturalny proces rozwoju oprogramowania.
  2. Tak, jak masz nie mutowalny obiekt to dziwne żebyś miał settery, co w związku z tym?

handluj z tym @cerrato oczywiście

Nie rozumiem.

ale tutaj zakładalem że mówimy o typowych setterach i getterach w klasach typu POJO

A co jest takiego niezwykłego w klasach POJO?

0
Aventus napisał(a):

Ale co dokładnie jest złą praktyką? Unikanie getterów i setterów, kiedy nic nie robią, czy może uniform data access, który pozwala ukryć szczegóły implementacji?

Unikanie getterow i setterow, a mówiąc dokładnie to unikanie ich dla tego ze AKTUALNIE nic nie robią. Pomijając kwestie możliwych zmian w przyszłości to używanie G/S tylko wtedy kiedy potrzebna jest jakaś dodatkowa logika wprowadza jedną chaotyczną rzecz do kodu- niekonsekwencje.

Są typy klas, które z założenia mają żadnej logiki. Są to niemutowalne klasy wartościowe. Wstawianie do nich getterów jest totalnie zbędne, więc dla konsekwencji można by nigdy tam getterów nie wstawiać. Już prędzej przydałby się nadpisany equals i hashCode (wygenerowany np Lombokiem), aczkolwiek to zależy od przeznaczenia. Microsoft zresztą zauważył problem i chyba szykuje się do wprowadzenia klas, które mają automatycznego equalsa i hashCode'a (oraz parę innych ekstra metod): https://blog.cdemi.io/whats-coming-in-c-8-0-records/

1
kulson napisał(a):

Co to znaczy, "szanowana jest tylko właściwość"? Dalej nie wiem, co to zmienia. Skoro odwolujesz się tak samo, jak do pola publicznego, a getter i setter są puste.

Chętnie bym zobaczył przykład, który nie skompiluje się po zamianie pustego get set na pole publiczne

O ile dobrze pamiętam, taki np DataGrid w WPF, operuje na właściwościach i raczej nie zmusisz go żeby wyświetlał zawartość pól publicznych.

1

@Wibowit:

Wstawianie do nich getterów jest totalnie zbędne, więc dla konsekwencji można by nigdy tam getterów nie wstawiać.

Czemu mialoby nie byc getterow w niemutowalnych klasach wartosciowych?

1
Aventus napisał(a):

Czemu mialoby nie byc getterow w niemutowalnych klasach wartosciowych?

A po co mają być?

0

A co jest takiego niezwykłego w klasach POJO?

To że to są klasy POJO czyli nie prawidze obiekty (takie z OOP). POJO to pojemniki na dane, nie ma mają żadnej logiki. Porównanie klasy reprezentującego okienko do klasy która reprezentuje model np. projektu informatycznego jest niezbyt trafne

  1. Wiele, bardzo wiele. I nie widzę w tym nic niezwykłego. Wymagania się zmieniają, logika się zmienia. Naturalny proces rozwoju oprogramowania.

Jesli masz logike w setterach to się ciesze że z Tobą nie pracuje :D Od logiki sa prawdziwe obiekty, nie settery

  1. Tak, jak masz nie mutowalny obiekt to dziwne żebyś miał settery, co w związku z tym?

To że powinno się za wszelką cene unikac mutowalności, zwłaszcza struktur danych. Settery kojarzą mi się z mutowaniem, a mutowania nieznosze. Oczywiście czasami może być przydatne, ale bardzo rzadko.

EDIT:
Okazało się że popełniłem błąd odnośnie POJO - mogą mieć logike. To co miałem na myśli to klasy w stulu Java Beans. W każdym razie chodziło mi o klasy typu pojemniki na dane ;)

1
scibi92 napisał(a):

A co jest takiego niezwykłego w klasach POJO?

To że to są klasy POJO czyli nie prawidze obiekty (takie z OOP). POJO to pojemniki na dane, nie ma mają żadnej logiki. Porównanie klasy reprezentującego okienko do klasy która reprezentuje model np. projektu informatycznego jest niezbyt trafne

  1. Wiele, bardzo wiele. I nie widzę w tym nic niezwykłego. Wymagania się zmieniają, logika się zmienia. Naturalny proces rozwoju oprogramowania.

Jesli masz logike w setterach to się ciesze że z Tobą nie pracuje :D Od logiki sa prawdziwe obiekty, nie settery

To ja się cieszę że z a Tobą nie pracuję jeśli czytasz "logika" i od razu myślisz "logika biznesowa". Ponadto jak sam napisałeś nie wiedziałeś nawet czym jest POJO, myśląc że to coś w rodzaju DTO.

  1. Tak, jak masz nie mutowalny obiekt to dziwne żebyś miał settery, co w związku z tym?

To że powinno się za wszelką cene unikac mutowalności, zwłaszcza struktur danych. Settery kojarzą mi się z mutowaniem, a mutowania nieznosze. Oczywiście czasami może być przydatne, ale bardzo rzadko.

No OK ale co to ma do rzeczy skoro dyskusja tyczy się publicznego wystawiania PÓL KLASY vs kontroli dostępu do nich za pomocą getterow i setterów? Ja o wozie, Ty o kozie. Po raz kolejny na tym forum powiem- masa ludzi ma tutaj ogromne problemy z logicznym myśleniem z tego co widać. Nie jesteście w stanie wymieniać argumentów na poziomie akademickim, czyli trzymać się tematu dyskusji.

0

Wydaje mi się, że nie powinno się mówić o czymś takim jak settery i gettery. Obiekty definiuje się nie po polach, a po ich zachowaniach czy też odpowiedzialnościach i na podstawie tego definiuje się ich interface (niekoniecznie jako interface w sensie osobny plik ICośtam tylko jako zbiór publicznych metod). I jeśli z definicji obiektu wynika to, że jest potrzebne coś jakby getter czy setter to on tam jest jako metoda (zachowanie tego obiektu) a nie jako getter/setter na pole. Znika wtedy problem pojęcia jak logika w setterzebo nie ma czegoś takiego setter.

2
kulson napisał(a):

A mnie zastanawia po co w c# stosuje się puste gettery i setery, czyli puste get i set?

Z tego samego powodu, dla którego w Javie stosuje się @Getter @Setter - aby oszczędzić kod. Przed C# 3.0 trzeba było samodzielnie implementować właściwości, pisać return w geterze i = value w seterze.

kulson napisał(a):

Co to znaczy, "szanowana jest tylko właściwość"? Dalej nie wiem, co to zmienia. Skoro odwolujesz się tak samo, jak do pola publicznego, a getter i setter są puste.

W programowaniu raczej rzadko pisze się wszystko samodzielnie, często trzeba korzystać z istniejących rozwiązań. Konwencja jest taka, żeby do upubliczniania danych nie stosować pól publicznych lecz właściwości i znaczna część istniejącego kodu działa w zgodzie z tą konwencją. Pożytku z przejścia na pola nie byłoby żadnego, ani to szybsze, ani czytelniejsze, ani mniej kodu do napisania.

Może gdyby język był projektowany teraz, to rozwiązane by to zostało w inny sposób, no ale przeszłości się nie zmieni.

Chętnie bym zobaczył przykład, który nie skompiluje się po zamianie pustego get set na pole publiczne

A jak się kompiluje, to znaczy, że jest poprawnie napisane i działa?

scibi92 napisał(a):

Dobre podejście jest w Groovym czy Kotlinie gdzie DTOsy kompilują się do bajtkodu Javovego i z punktu widzenia Javy niby je masz, ale w kodzie operujesz po polach, a gdyby coś sie naprawde stało i rzeczywiście potrzebował tych setterow/getterów to łatwo dodac, jest to nawet lepiej zrobione niż w tym cudownym i nowoczesnym C#.

Bardzo z d**y ten pojazd, bo zarówno Groovy jak i Kotlin są od C# nowsze.
I jak rozwiązane jest to, że dla klienta takiego modułu nie jest to breaking change? Na poziomie bajtkodu pole może być czymś więcej niż tylko polem?

A najlepiej robić niemutowalne obiekty DTO i dawać wszystko przez konstruktor.

Nie wiem czy najlepiej - strata czasu, która nie zabezpiecza przed niczym, no chyba, że ktoś przepycha DTO przez wiele warstw. Tylko to wtedy nie są DTO tylko ADM, a to temat na inną dyskusję.

scibi92 napisał(a):

1)Ile razy musiałes robić inną implementace setterów i getterów?

To chyba bez znaczenia - nawet jeśli zajdzie taka potrzeba raz w życiu, to i tak to będzie breaking change. Czy istnieje jakiś zysk z posiadania pól zamiast właściwości, który warty jest ryzykowania wprowadzenia później breaking change?

2)Nie musisz stosować setterow jesli tworzysz niemutowalny obiekt

Raczej "nie możesz" niż "nie musisz".

Tak czy siak, mutowalność nie ma się nijak do stosowania getterów, a właściwości jako oddzielna konstrukcja i konwencja języka, to jeszcze jakby trzeci temat, który również nie stoi w sprzeczności z mutowalnością. Więc o co tutaj właściwie chodzi?

0

To polecieliście panowie. Ciekawe czy OP coś zrozumiał z tematu.

0

Podsumowując: ogólnie lepiej mieć za dużo getterów niż za mało. Nie dotyczy to jednak setterów - tych nigdy nie jest za mało.
Jeśli chodzi o klasy-pojemniki na dane, zdania są podzielone. @Aventus argumentuje, że nigdy nie wiadomo, kiedy klasa przestanie być prostym pojemnikiem na dane. Inni uważają, że jest to na tyle rzadkie, że ewentualna korekta kodu będzie trywialna.

Ergo: trzeba pisać w językach z natywną obsługą właściwości i mieć wszystkie bitwy get vs. public w dupie.

@Nindzia: Jeżeli nie wiesz, czy pisać gettery i settery - pisz je.

0 użytkowników online, w tym zalogowanych: 0, gości: 0