@kamillapinski: myślę że nie wyciągnąłeś pełnego sensu moich wypowiedzi. Owszem, wymieniłem możliwość zmian ale za jeszcze większe zagrożenie wymieniłem niekonsekwencje w kodzie. Dla przykładu- zaglądając do jakiejś klasy gdzie stosuje się mieszane gettery jak i pola publiczne potrzeba więcej czasu i uwagi na przeskanowanie tejże klasy i wywnioskowanie jakie wartości i obiekty wystawia. Nie mówiąc już o tym że
order.setDescription("blah");
order.count++;
Wyglada po prostu brzydko.
somekind napisał(a):
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?
Tych "breaking change" robi się w ciągu życia projektu mnóstwo. Enkapsulacja pola za pomocą akcesorów to kilka kliknięć w IntelliJu: https://www.jetbrains.com/help/idea/encapsulate-fields.html
Wibowit napisał(a):
Enkapsulacja pola za pomocą akcesorów to kilka kliknięć w IntelliJu: https://www.jetbrains.com/help/idea/encapsulate-fields.html
Tylko w jaki sposób łatwość refaktoryzacji przez IDE rozwiązuje problem z breaking change?
Podaj jakiś przykład z życia wzięty, że ten problem wykracza poza refaktor.