Wpis z mikrobloga

Wszystko zależy od przypadku użycia, o ile tzw. modele domenowe powinny być bogate, stosować enkapsulację/hermetyzację etc.o tyle proste kontenery na dane, które się przerzuca pomiędzy warstwami jak np. DTO lub ViewModel dla warstwy prezentacji jak najbardziej powinny być płaską strukturą ze zbiorem "getterów" i "setterów".
@spetz jak masz prostą strukturę typu DTO lub ViewModel to po co Ci te gettery i settery? bronisz rozwiązania, które nie ma żadnego sensu. Zrób zwykłe pola public i tyle.
@spetz: ja oczywiście nie bronię autora artykułu, miałem z nim już wcześniej styczność i to zwykły oszołom ( ͡º ͜ʖ͡º) Nie zmienia to faktu, że dorzucanie do DTO getterów i setterów nie ma prawdopodobnie ani jednego logicznego argumentu. Ludzie są po prostu moim zdaniem błędnie przyzwyczajeni do takiego sposobu pisania kodu. Im wcześniej się to wypleni tym lepiej
@podubin: dobra ale jak zmienisz pole (np. masz stringa ale zmieniasz na inny obiekt) w DTO i masz getter i setter to mozesz zachować kompatybilonsc wstecz (np. zamiast zwracac string zwracasz .toString()), jak masz pola public to nie zmienic nic, bo nie wiesz kto i gdzie go używa. Nawet głupie gettery i settery maja sens
@GruncleStan: dawno nie słyszałem tak słabego argumentu, żeby nie powiedzieć głupiego. Możliwe, że jest on adekwatny w pisaniu aplikacji jak u autora tekstu new Dog().setBall(new Ball()) ( ͡º ͜ʖ͡º)
@GruncleStan: ja wyraziłem swoje zdanie i nie podawałem żadnego przykładu. Ty natomiast podałeś argument z książki o OO, który nie ma moim zdaniem odniesienia do rzeczywistości. Różnica jest taka, że ja potrafiłem swoje zdanie wyrazić w sposób ludzki, a Ty jesteś stereotypowym pryszczatym głąbem, który pluje jadem w internecie