[Atraktor]

W przypadku dostępu do prywatnych pól, kiedy jest taka potrzeba, lepiej/bardziej elegancko jest używać getterów i setterów, czy friend function?
#cpp #programowanie

[P.....s]

@Atraktor: getterów i setterów

[JakTamCoTam]

@Philopolemus_Fronius słyszałem, że jak ktoś używa getterow i setterow w c++ to coś jest nie tak

[P.....s]

@JakTamCoTam: to bardzo dziwnie słyszałeś xd

[Khaine]

@JakTamCoTam: Ke? My w pracy mamy framework C++ który jest z 98 roku (tak, dobrze widzisz) i ma gettery i settery zaszyte już w sobie, razem z całym konceptem propertisów takim jak jest w Javie czy C#. Nawet ma sklejone pliki .h z plikami .cpp tak jak w językach wyższego poziomu. Rozbicie pliku na .h i .cpp następuje dopiero za kodem źródłowym w sposób automatyczny.

Co by nie mówić o

[JakTamCoTam]

@Philopolemus_Fronius
@Khaine juz nie wiadomo komu ufać w 2k18

[P.....s]

@JakTamCoTam: no to może powiedz co jest nie tak w używaniu getterów i setterów?

[Khaine]

@JakTamCoTam: A co chcesz osiągnąć? Bo tak naprawdę masz tutaj dwa rezultaty.

1. Friend function sprawia, że pole jest prywatne CHYBA ŻE korzysta z niego ta funkcja. Ona ma wtedy dyspensę od papieża na używanie tego, ale tak ogólnie jest nadal prywatne. Więc nie tracisz prywatności a jedynie naginasz zasady dla jednej funkcji.

2. Get/Set daje publiczny dostęp do pola prywatnego, więc prywatne pole jest tylko z nazwy tak naprawdę.

[j.....4]

@Philopolemus_Fronius: Prawdopodobnie chodzi o to, że gettery/settery(ale bardziej settery) = słaby design oop(z wyjątkami). W przypadku getterów jest to głównie semantyczna sprawa np. .getWidth() -> .width() (osobiście używam prefixy "getterów" tylko gdy zwrócona wartość może nie być dostępna w momencie jej otrzymania np. std::future, QNetworkReply z Qt), a w przypadku setterów często psuje immutability obiektów oraz nie pasuje do używanego w oop indirect transfer of control, bo to obiekt powinien

[P.....s]

@jk64: poleciłbyś jakąś książkę o obiektowym podejściu do projektowania oprogramowania, dobrych praktykach itp?

[j.....4]

@Philopolemus_Fronius: IMO Clean Architecture Roberta C. Martina daje rade.

[P.....s]

@jk64: dzięki

[Saly]

@Atraktor: rób public. W javie ma to sens, bo system typów jest prosty i masz jeden typ wartości na typ a nie 3 albo więcej. Do tego mania na gettery/settery w javie ma podłoże historyczne: pierwsze wersje ejb wymagały dostęp do zmiennych przez metody. Jeżeli masz klasę, która składa się z samych getterow/setterów to lepiej zrób wszystko na publicach. Argument, że gettery/settery pozwalają na zmianę zachowania np. walidacja to bullshit: